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[57] ABSTRACT 

In view of providing a network system enabling communi- 
cation having passed fire walls (repeaters) and assuring high 
security and operation flexibility through access control 
based on users and applications, a user-held table indicating 
correspondence between repeaters and passwords, a 
repeater-held table indicating correspondence between users 
and passwords and a table indicating access regions are 
defined respectively for users, departments of users and 
official positions of users and a route control information 
storing table indicating correspondence between networks 
and next transmitting destination is also provided to execute 
the access control for each user. Moreover, the repeater is 
provided with the repeating route control table so that a 
repeater located in the course of route to the transmitting 
destination computer and allowing communication from the 
transmitting side computer is selected from the data repeat- 
ing control table and the process for requesting the repeating 
operation of communication with the destination is executed 
to the selected repeater. 
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REPEATER AND NETWORK SYSTEM network, such routing information must be obtained with a 

UTILIZING THE SAME certain method. FIG. 1 shows an example of the problem 

explained above. When a client exlOl attempts to make 

BACKGROUND OF THE INVENTION communication with a server accommodated in the network 

5 exl06 of A corporation, an external fire wall ex 102 repeats 

The present invenlion relates to security of a computer the communication. Since the external fire wall exl02 can 

connected to a network system and particularly to a method obtain the routing information to the server cxl04 for 

of constituting a network system which executes access communication with the server exl04 in the network exl06 

control and relays communications of applications through of A corporation, communication can be repeated. However, 

mutual cooperation of fire walls. JQ since the server exlOS is concealed by the internal fire wall 

As a method of preventing invasion into a computer exl03 for the communication with the server exlOS accom- 

through a network, a repeater (fire wall) has been proposed modated in the sub-network exl07, the external fire wall 

to give restriction to the access from outside. exl02 cannot obtain the routin g inforoution to the server 

..... „ , . * j . exlOS and thereby this communication cannot be repeated. 

A typical fire wall has a taction, as * describee 1 "Com- Mq . ^ ^ f communication between two 

puterSecunt) '^source Clearinghouse of NIST (National 1S net works connected through the external network, this com- 

Insutute of Standards and Technology), to control the munication cannol ^ rea B Uzed between respective internal 

accesses depending on IP (Internet Protocol) addresses of ^ walls> unlcss thc routing mformation for identifying the 

the transmitting side and receiving side and kinds of services internal fire waU is set for the external fire wall, 

and to the store access record. FIG. 2 shows an example of the problem explained above. 

Moreover, as a repeater for repeating communication 20 a client ex201 accommodated in the network ex210 is 

between a client and a server, there is provided socks V5 capable of making communication with a server cx202 in 

proposed by RFC1928 in the environment where fire walls the network ex21I by registering the fire wall ex206 as the 

exists. In the socks, mutual identification between the client route to thc server ex202 in the fire wall ex205. However, 

and the repeating server and socks protocol for realizing when a server ex204 is provided in the internal sub-network 

connection instruction for the repeating server are defined 25 ex214 of the network cx213, since the route is concealed by 

and thereby communication between the client and the the fire wall ex208, the internal fire wall ex209 cannot be 

server having passed one fire wall can be realized. registered in the fire wall cx207. 

Moreover, there is a gateway protocol such as RIP OBJECT AND SUMMARY OF THE INVENTION 

(Routing Information Protocol: RFC 1058), OSPF (Open . , . . ^ f . . 

Sbortes.Path First: RFC 1131), etc. as . mechanism to 30 'berefore an object of the present mvention to prov.de 

realize dynamic exchange of repeating route information in " lUgt ^ ^Tf T ^ 

the IP la er having passed the fire wall and repeaters (fire walls) used in 

«r i/^ 1 - \ lhe same nelwork DV solving the problems explained above 

With rapid development of Internet system, a person can and offeriri g a means for exchanging the repeating route 

get various kinds of information generated in the world on 35 information among a plurality of repeaters (fire walls). 

the real-time basis but on the other hand, a person is in turn Mokovct, it is also an object of the present invention to 

threatened to external invasion As effective measures for idc a DCtwork ^ J whicfa ^ and 

such external invasion, it has been proposed to (1) eivc u* u *• a ■i_-r. j . _i 

.. . . Tn , , * . . . F 1 "^^ w yj h\ v ^ assures higher operation flexibility and repeaters used 

Umitation on IP address for making access to each service lhcrcin ± h tQC acocss conlroI bascd Qn £ ^ 

and to (2) provide a gateway (fire wall in narrow sense) to 4Q uscrs and applicatioDS . 

store the access record. Use of such fire wall in narrow sense .. . • , . . , .... 

has enabled reduction of threat for an external invader by f . ° b)eCtS eXplamed ab ° Ve WlU achieved using 

. . . — - . * following means, 
acquiring matching property of the operating environment of /1X A . , . 
tK* ; tM ir °„ A w r ■ .u t . i u (!) Access control based on computer users and applications 
the gateway itself and localizing the ranee of control by an ~ . . r . . . 
administrator Executing access control as an object of access control on 
T _ '. 45 the basis of computer users and applications 
However, in the case of executing the access control (2) Identification of computer users and applications 
utilizing the technique of the related art, since the access identifying, for executing access control, that the corn- 
control object is based on the information incorporated to a murj icaiion is requested by a person who has issued the 
computer such as class of service and IP address, there is a "request 

problem that the access control based on users cannot be 50 (3) Data t " ransfcr in thc teH havi lfac acccss CQnlrol 

realized. For example, desired access control becomes function 

impossible for the computer to which the IP address is Pr0 viding transparency of communication in the commu- 

assigned dynamically and class of service »s limited to nication between computers having the access control func 

particular users. lions 

Moreover, in private network utilizing the Internet, a fire 55 The data transfer by the repeaters can be realized by 

wall plays a very important role for security and an internal providing, in the repeater, a repeating route control table 

fire wall is increasingly installed in the private network in storing correspondence between the address of the transmit- 

order to protect the sub-network. There are several problems lmg side computer and the address of the repeater provided 

to be solved for the communication in the environment t 0 transfer the data to such address and executing the 

where a plurality of fire walls exist. For example, when the 60 processing to select, from the data repeating route control 

communication having passed the internal fire wall for uble, the repeater provided in the course of the route to the 

protecting the sub-network is to be attempted from a com- target computer in the receiving side to enable the comrau- 

puter of an external network, the communication must be nication from the computer of the transmitting side and the 

repeated between the external fire wall and the internal fire processing to connect the repeating program of the repealer 

wa ^" 65 identified by the processing explained above to request the 

However, since the routing information for the internal repeating of communication with the receiving side to the 

fire wall provided for repealing is concealed to the external repealer. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
While the present invention has been described in detail 
and pictorially in the accompanying drawings it is not 
limited to such details since many changes and modifica- 
tions recognizable to those of ordinary skill iD the art may be 5 
made to the invention without departing from the spirit and 
the scope thereof. Other objects and advantages of the 
present invention will be apparent from the following 
detailed description of the presently preferred embodiments 
thereof, which description should be considered in conjunc- io 
tion with the accompanying drawings in which: 

FIG. 1 is a diagram (No. 1) for explaining problems of the 
related art; 

FIG. 2 is a diagram (No. 2) for explaining problems of the 
related art; 1S 

FIG. 3 is a diagram showing a structure of the network 
system as a whole; 

FIG. 4 is a hardware block diagram; 

FIG. 5 is a diagram showing a software structure of a 
repeater; 20 

FIG. 6 is a diagram showing a software structure of a 
terminal unit; 

. FIG. 7 is a diagram showing a packet format; 
FIG. 8 is a diagram showing the communication sequence ^ 

FIG. 9 is a diagram showing a terminal unit control 
flowchart 1; 

FIG. 10 is a diagram showing a repeater control flowchart 

1; 

FIG. 11 is a diagram showing the communication 
sequence 2; 

FIG. 12 is a diagram showing a terminal unit control 
flowchart 2; 

FIG. L3 is a diagram showing a repeater control flowchart 35 

2; 

FIG. 14 is a diagram showing a format of user identifi- 
cation information table; 

FIG. 15 is a diagram showing a format of apparatus 
identification information table; 40 

FIG. 16 is a diagram showing a format of user access 
control table; 

FIG. 17 is a diagram showing a format of section access 
control table; 

FIG. 18 is a diagram showing an example of accessible 45 
region; 

FIG. 19 is a diagram showing an example of a hierarchical 
network structure; 

FIG. 20 is a diagram showing a format of official position 5Q 
access control table; 

FIG. 21 is a diagram showing a format of repeating path 
information table; 

FIG. 22 is a diagram showing a mutual identification 
method 1; 55 

FIG. 23 is a diagram showing a mutual identification 
method 2; 

FIG. 24 is a diagram for explaining dynamic path control; 

FIG. 25 is a diagram for explaining a protocol conversion 
function; and 60 

FIG. 26 is a diagram showing a format of table storing 
application logs. 

DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS fi5 

Preferred embodiments of the present invention will be 
explained below. 



The network system as an object in this embodiment has 
following characteristics. 

(a) For distribution of data packet among communication 
apparatuses, distribution functions such as TCP 
(Transmission Control Protocol)/IP (Internet Protocol), 
OSI (Open Systems Interconnection), etc. are used. 

(b) For data transfer, a repealer having access control 
function is provided. 

Next, the structure of this network system will be 
explained with reference to FIG. 3 to FIG. 6. 

FIG. 3 shows an example of the structure of this network 
system. 

The network system of the present invention has structure 
that a plurality of networks 1 accommodating terminal units 
3 are connected via repeaters (fire wall) 2. In this system, the 
repeaters 2a to 2d are capable of processing the TCP/IP, OSI 
protocol, etc., has distribution function of OSI data packet 
and is also provided with the access control function. In the 
explanation of this embodiment, the repeater is described as 
a fire wall. The terminal units 3a to 3/ are computers 
installed in each user site. The networks la to le mean the 
networks such as the LAN (Local Area Network) and private 
line, etc. 

FIG, 4 shows the structure of repeater 2 as an example of 
the hardware structure of the repeater 2 and the terminal unit 
3 of a user site. The repeater 2 includes a processor 21 for 
controlling hardwares, a memory 22 for storing programs 
and transmitting/receiving messages, a line controller 23 for 
controlling input and output of signals to/from LAN and 
private line and a terminal input/output controller 24 for 
controlling a display and a keyboard connected to the 
apparatus. The repeater 2 is connected with a display and 
keyboard 25 as input/output devices. 

FIG. 5 shows the software structure of the repeater 2 
formed depending on the hardware structure shown in FIG. 
4. 

The software of the repeater 2 includes a storing section 
201 for storing the repeating control information and access 
control information for transferring and filtering data packet, 
a data repeating control section 202 for offering the function 
to transfer the data packet to the target terminal unit depend- 
ing on the repealing control information and the filtering 
function to discard of the data packet, a link control section 
203 provided in a line control section 23 and a terminal input 
and output control section 24 to work as an external interface 
control section to control input and output of the LAN and 
private line and the terminal unit, a program scheduler 204 
for scheduling and administrating program execution of the 
storing section 201, the data repeating control section 202 
and the link control section 203 and a log storing section 205 
for storing user application log. 

The above functions of the software of the repeater 2 is 
realized by the processing performed by the processor 21. 

In addition, the software executed by the processor 21 is 
stored in the memory 22, for example. 

The program may also be retrieved from a storage 
medium such as floppy, ROM, etc or from a storage of a 
server connected to a network which is connected to the 
repealer, and stored in the memory 22. 

In the repeating control information being stored in the 
storing section 201, a destination address information of the 
terminal unit (position of terminal unit, terminal unit name, 
etc.) and a next transmitting address information for sending 
data to the destination address are registered. Moreover, in 
the access control information, a user name, various 
attributes of user (department, official position, available 
services and accessible range, etc.) are registered. 
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FIG. 6 shows the software structure of a terminal unit 3 
formed depending on the hardware structure shown in FIG. 
4. 

The software of the terminal uait 3 includes a storing 
section 301 for storing data transmitting and receiving 
control information as the route information for transmitting 
and receiving data packet and data transmission and recep- 
tion information, a data transmission and reception control 
section 302 for controlling transmission and reception of 
data packet to and from the target terminal unit depending on 
this route information, an external interface control section 
303 provided in a line control section 23 and a terminal input 
and output control section 24 to control the input and output 
of the LAN and private line and terminal unit, a plurality of 
application programs 304a to 3046 operating on the terminal 
unit 3, a program scheduler 305 for scheduling and admin- 
istrating program execution of the storing section 301, data 
transmission and reception control section 302, external 
interface control section 303 and application programs 304, 
a data repeating control information section 306 to deter- 
mine the transmitting destination of the data packet stored in 
the storing section 306 and a data repeating control section 
307 for offering the function to transmit the data packet to 
the target repeater depending on the data repeating control 
information. 

The above functions of the software of the terminal unit 
3 is realized by the processing performed by the processor 
21. 

In addition, the software executed by the processor 21 is 
stored in the memory 22, for example. T 

The program may also be retrieved from a storage 
medium such as floppy, ROM, etc or from a storage of a 
server connected to a network which is connected to the 
terminal unit, and stored in the memory 22. 

Next, the packet format and outline of the transmission 
procedures are explained with reference to FIG. 7 to FIG. 
12. 

FIG. 7 shows an example of the packet format used in this 
embodiment FIG. 7(A) shows a format of the connection 
request packet PI for requesting start of communication, 
while FIG. 7(B) shows a format of the connection confirm- 
ing packet P2 and FIG. 7(C) shows a format of the data 
transfer packet P3. 

Each packet is writing a class of packet in the first field, 
an operating method in the second field and data in the third 
and subsequent fields. In the case of the connection request 
packet PI for requesting start of communication, "CON- 
NECT is set to the first field Pll, "req" is set in the second 
field P12 indicating the operating method. In regard to the 
third field P13 and subsequent fields for transferring data, 
"transmitting destination terminal unit name" is set in the 
third field P13, "service name" in the fourth field P14 and 
"user information" to the fifth field P15. In the user infor- 
mation field P15, the user identification information and 
transmitting side terminal unit name are stored. 

In the connection confirming packet P2 indicating the 
response for start of communication, "CONNECT" is set to 
the first field P21, "conf ' to the second field P22 and "code" 
to the third field P23. In the code third field P23, the codes 
indicating "allowing connection setup", "user identification 
error", "out of accessible range", etc. and information 
including names of repeater which has generated such codes 
and transmitting destination terminal unit are stored as the 
information indicating the condition of the communication 
starting operation. 

In the data packet P3 used under the communicating 
condition, "DATA" is set to the first field P31, "null" to the 
second field P32 and "data" to the third field P33. 
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FIG. 8 shows the sequence of communication procedures 
by making access to the terminal unit 3e from the terminal 
unit 36 in the system shown in FIG. 3. 
In this embodiment, prior to start of communication with 
5 the target terminal unit, the communication route is estab- 
lished using a packet for declaring start of communication. 
The connection request packet PI is the packet for declaring 
start of communication. The terminal unit 3b transmits, prior 
to start of communication, the connection request packet PI 
10 having designated the terminal unit 3e as the destination 
address of the target terminal unit in the third field P13 to the 
repeater 2c (SI). 

In the repeater 2c, a user is identified depending on the 
user identification stored in the user information field P15 of 
is the connection request packet PI and thereafter it is judged 
whether a user is capable of using the repeater 2c or not (S2). 
When a user is judged to be capable of using the repeater, the 
connection request packet PI received is transferred to the 
next repeater Id in order to transmit the connection request 
20 packet PI to the target terminal unit (S3). In the repeater 2d, 
when a user is also judged to use the repeater (S4) in the 
same manner as those for the repeater 2c, the connection 
request packet PI is transmitted to the target terminal unit 
(S5). 

25 In the terminal unit 3e, after a user is identified (S6), the 
connection confirming packet P2 having set the normal code 
"allowing connection setup" in the code field P23 is trans- 
mitted to the terminal unit 3b in the transmitting side as the 
response to the connection request packet PI (S7). Thereby, 

30 the communication route is established between the terminal 
unit 3b and the terminal unit 3e and data communication 
may be started to transfer the data packet P3 (S8). 

FIG. 9 shows a control flowchart for executing the com- 
munication start processing prior to start of communication 

35 by the terminal unit 3b with the target terminal unit. The 
connection request packet PI designating the target terminal 
unit 3e in the destination terminal unit name field P13 is 
transmitted to the repeater 2c (S10). Upon reception of the 
connection confirming packet P2 as the communication 

40 route setup response packet, reference is made to the code 
field P23 of the connection confirming packet P2 (Sll). 
When the code field P23 is normal, data transfer is started 
(S12) but if the code field P23 is irregular, communication 
is completed (S13). 

45 FIG. 10 shows a control flowchart for executing commu- 
nication start processing by the repeater 2c with terminal 
units. 

When a packet receiving section 202a, included in the 
data repeating control section 202, receives the connection 

50 request packet PI having designated the target terminal unit 
3e as the destination (S21), user identifying section 2026, 
included in the data repeating control section 202, refers to 
the user information field P15 stored in the connection 
request packet PI to identify a user (S22). When irregularity 

55 is not detected as the result of user identification, accessible 
range of user and matching between terminal units in the 
transmitting and receiving sides are checked by a checking 
section 202c, included in the data repealing control 202, that 
checks range and matching according to a user attribute 

60 table in the data repeating control information/access control 
information 201. The checking section 202c controls access 
to the terminal or service. The table stores correspondence 
between at least one attribute of at least one user and 
accessible range of networks. (S23). When the accessible 

65 range is satisfied, the destination terminal unit name field 
P13 of the connection request packet Pt is compared with 
the self terminal unit name as the repeating operation by a 
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comparing section 202d included in the data repeating 
control section 202 (S24). Since the repeater 2c is operating 
as a repeater and content of the destination terminal unit 
name field P13 docs not match the self terminal unit name, 
a determining section 202e, included in the data repeating 5 
control section 202, determines the next repeating unit name 
with reference to a repeating route control table 201a in the 
data repeating control information/access control informa- 
tion 201 (S25). Next, a packet transmitting section 202/ 
included in the data repeating control section 202 transmits 10 
the connection request packet PI (S26). When the connec- 
tion confirming packet P2 is received as the response of the 
connection request packet PI, the connection confirming 
packet P2 received is transferred to the terminal unit 3b 
which transmitted the connection request packet PI by a is 
transferring section 202g included in the data repealing 
control section 202 (S27). Moreover, reference is made to 
the code field P23 of the connection confirming packet P2 by 
a referring section 202A included in the data repeating 
control section 202 (S28). When the code field P23 is 20 
normal, data transfer is started (S29), but if the code field 
P23 is irregular, communication is completed (S31). If 
irregularity is detected as the result of user identification at 
step S22, the connection confirming packet P2 setting the 
error code "irregular user identification" in the code field 25 
P23 is transmitted to the terminal unit 3b which has trans- 
mitted the connection request packet PI by the transmitting 
section 202/ (S30) and the communication is completed 
(S31). 

When output of accessible range is judged at step S23, the 30 
connection confirming packet P2 setting the error code "out 
of accessible range" in the code field P23 is transmitted to 
the terminal unit 3b which has transmitted the connection 
request packet PI (S30) and communication is completed 
(S31). 35 

This control flowchart includes the operations in the 
destination terminal unit. When the destination terminal unit 
name field P13 matches with the self terminal unit name at 
step S24, the self terminal unit is judged as the destination 
terminal unit in this control flowchart and the connection 40 
confirming packet P2 setting the normal code "allowing 
connection setup" in the code field P23 is transferred to the 
terminal unit 3b which has transmitted the connection 
request packet PI (S32) to start the data transfer (S29). 

FIG. 11 shows a modification example of the other 45 
embodiment of the communication procedure sequence for 
making access to the terminal unit 3e from the terminal unit 
3b. In the example of sequence shown in FIG. 9, the 
connection request packet PI is sequentially transferred by 
the repeaters, the repeaters must be in the reliable condition 50 
with each other. Meanwhile, the example of sequence in this 
embodiment indicates that the repeaters are not in the 
reliable condition with each other. 

First, prior to start of communication with the target 
terminal unit, a communication route is established using the 55 
packet for declaring start of communication. The connection 
request packet PI is the packet for declaring start of com- 
munication. A terminal unit 3b transmits, prior to start of 
communication, the connection request packet PI designat- 
ing the target terminal unit 3e as the destination to the 60 
repealer 2c (S40). In the repeater 2c, after user identification 
is performed depending on user identification stored in the 
user information field P15 of the connection request packet 
PI, a user is judged to be capable of using the repeater 2c or 
not (S41). When a user is judged to be capable of using the 65 
repeater, the connection confirming packet P2 is transmitted 
to the terminal unit 3b in the transmitting side (S42). 
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Upon reception of the connection confirming packet P2 
from the repeater 2c, the terminal unit 3b transmits again the 
connection request packet PI designating the target terminal 
unit 3e as the destination to the repeater 2c. Tbe repeater 2c 
transfers in turn this connection request packet PI to the 
repeater Id (S43). 

In the repeater 2d, when a user is judged to be capable of 
using the repeater 2d in the similar procedures as those for 
the repeater 2c (S44), the connection confirming packet P2 
is transmitted to the terminal unit 36 of the transmitting side 

(545) . 

Tbe terminal unit 3b in the transmitting side transmits, 
upon reception of the connection confirming packet P2, the 
connection request packet PI designating the target terminal 
unit as the destination to the repealer 2c. The repeaters 2c 
and 2d transfer this packet PI to the target terminal unit 3e 

(546) . 

The destination terminal unit 3e identifies a user depend- 
ing on user identification stored in the user information field 
P15 of the connection request packet PI (S47) and transmits 
the connection confirming packet P2 to the terminal unit 3b 
in the transmitting side as a response to the connection 
request packet PI (S48). Thereby, the communication route 
can be set up between the terminal unit 3b in the transmitting 
side and the destination terminal unit 3e, data communica- 
tion can be started and data packet P3 can be transmitted 
(S49). With execution of repeated communication route 
setup request, user identification for the terminal unit 3b in 
the transmitting side is performed for each repeater and 
services of this invention can also be offered even when 
reliable condition is not yet established among the repeaters. 

FIG. 12 shows a control flowchart for executing the 
communication start processing prior to start of communi- 
cation by the terminal unit 3b with the target terminal unit 
3e. The connection request packet PI designating the target 
terminal unit as the destination in the destination terminal 
unit name field P13 is transmitted to the repeater 2c (S50). 
Thereby, when the connection control packet P2 which is the 
communication route setup response packet is received in 
turn, whether connection to the target terminal unit 3e is 
completed or not is judged (S52) by referring to the code 
field P23 of tbe connection confirming packet P2. When the 
packet P2 is issued to confirm the connection from the 
repealer, the connection request packet PI is transmitted 
again to the repeater 2c (S53) and operation returns to the 
step S51. When the packet P2 is issued to confirm the 
connection from the terminal unit 3e, data transfer is started 
(S54). 

FIG. 13 shows a control flowchart for executing commu- 
nication start process by the repeater 2c with a terminal unit 
depending on the sequence shown in FIG. 11. The repealer 
2c starts, upon reception of the connecting request packet PI 

(560) designating the target terminal unit 3e as the 
destination, the data repeating condition checking process 

(561) . The connection request PI is the first request received 
by the repeater 2c and the data repeating condition is in the 
initial condition. Therefore, user identification process is 
started (S64) by referring to the user information field P15 
stored in the connection request packet. 

When irregularity is not detected as the result of user 
identification, the allowable accessible range of user and 
matching between the terminal unit in the transmitting side 
and destination terminal unit is checked (S65). When the 
allowable accessible range is satisfied, the connection con- 
firming packet P2 setting the normal code "repealing of 
connection is possible" in the code field is transferred to the 
transmitting side terminal unil 3b (S66) to start the data 
transfer condition (S67). 
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Next, when the connection request packet PI is received 
(S60), since the data transfer operation (data repeating) is 
performed at step S61 for checking the condition, the 
connection request packet PI is judged to be received and 
the repeater is determined (S62) to transfer the connection 5 
request packet PI (S63) by referring to the repeating route 
control table. At step S64, if irregularity is detected as the 
result of user identification, the connection confirming 
packet P2 setting the error code "irregularity of user iden- 
tification" in the code field P23 is transmitted to the terminal 10 
unit 36 which has transmitted the connection request packet 
PI (S70) to complete the communication (S71). 

At step S65, when the request is out of the accessible 
range, the connection confirming packet P2 setting the error 
code "out of the accessible range" in the code field P23 is is 
transmitted to the terminal unit 36 which has transmitted the 
connection request packet PI (S68) to complete the com- 
munication (S69). 

Next, outline of user identification performed in the 
communication procedures will be explained with reference 20 
to FIG. 14 and FIG. 15. In this embodiment, a password 
identification method will be explained. Various identifica- 
tion methods such as the identification mechanism using a 
public key and individual identification mechanism have 
been proposed and this embodiment can be applied to any 25 
type of identification mechanism. 

FIG. 14 shows a table storing an identification informa- 
tion for utilizing each repeater held by a user 1. The 
user-held identification information table 400 is constituted 
by a repeater name 401 in which the repeater name is 30 
described and an identification information 402 in which a 
password information required for identification in each 
repeater is described. In this example, a user (user 1) is 
capable of using only the repeater la and it has a password 
"test". When a user (user 1) makes communication via the 35 
repeater 2a, it is requested to set this identification infor- 
mation in the user information field P15 of the connection 
request packet PI. 

FIG. 15 shows a table 410 storing the user identification 
information held by the repeater 2a. In the repeater- held 40 
identification information table 410, a user name 411 and a 
password information 412 of each user are described. In this 
example, the password of user (user 1) is set to "test", 
password of user (user 2) to "abedx", the password of user 
(user 3) to "poisd" and the password of user (user 4) to 45 
"odksci". In this case, if the identification information 
described in the table is stored in the user information field 
P15 of the connection request packet PI when an user 1 to 
4 attempts communication via the repeater 2fl, such user is 
identified as the user himself (S22, S64) and the next access 50 
control is started (S23, S65). 

Next, outline of the access control, to be executed in a 
company organization as an example, in the communication 
sequence will be explained with reference to FIG. 16 to FIG. 

20. 55 

FIG. 16 shows a table 420 storing user access control 
information, which are user attributes, held by the repeater 
2a. In the user access control table 420 held by the repealer, 
user name 421 of each user, department 422 to which user 
belongs, official position of user 423, transmitting side 60 
network 424 to which a user can make access, destination 
network 425 to which a user can make access and services 
426 which a user can receive are respectively described. 

In this example, a user (user I) can make access to the 
network la or network 16 from the network la or network 65 
16 and the service which a user (user 1) can receive is only 
the file transfer. A user (user 2) can make access to the 



network lc or network le from the network lc or network 
le and a user (user 2) can receive any kinds of services 
because "•" is indicated in the service column 426. A user 
(user 3) can make access to any network from any network 
because "*" is indicated in the transmitting side column 424 
and destination column 425 and can receive the virtual 
terminal service. A user (user 4) can make access to any 
network from any network and can receive any services 
because is indicated in the transmitting side column 424, 
destination column 425 and service column 426. The aster- 
isk mark "*" indicated in the table means the accessible 
networks and receivable services. The sign "-" means that 
(he item given this mark is not available. As explained 
above, the regions on the network which a user can use are 
defined in the transmitting side column 424, destination 
column 425 and service column 426. 

FIG. 17 shows a table 430 storing an access control 
information of department, which are also user attributes, 
held in the repealer 2a. The access control table 430 of 
department held in the repeater describes, for each 
department, department name 431, accessible destination 
network 432, accessible transmitting side network 433 and 
available service 434. In this example, the department 
"Planning" is capable of making access to the networks 16, 
lc, Id and le from the networks 16 or Id and can receive 
only the virtual terminal service. Namely, the regions on the 
network which each department can use are defined in the 
destination column 432, transmitting side column 433 and 
service column 434. As explained, the regions on the net- 
work can be defined not only for users but also for one 
attribute. The asterisk mark"*" described in the table means 
the accessible network and receivable services. The sign 
means that the item given this mark is not available. 

FIG. 18 shows the accessible regions which can be 
formed depending on the access control information of 
department. This figure shows the accessible regions of 
department defined by each table explained above. The 
accessible region 40a of the Department of General Affairs 
is the network la and network 16, while the accessible 
region 40c of the Department of Development and Design is 
the network 16, network lc and network le, and the acces- 
sible region 406 of the Department of Planning is the 
network 16, network lc, network Id and network le. 

As explained above, in this embodiment, the accessible 
terminal units and application region such as network can be 
defined for each user depending on the various attributes 
held by user and moreover the accessible region can also be 
defined for attribute. As explained, the application regions 
constituted on the network can form the logical networks for 
each user, each department and each official position. 

FIG. 19 shows the accessible regions when structure of 
the departments are hierarchically indicated. In this 
example, the Department of General Affairs 516 of factory 
A connected to the network 526 of factory A and the 
Department of General Affairs 51c of factory A connected to 
the network 52c of factory B can form the accessible region 
53 which enables the same work, namely the logical network 
by defining the Department of General Affairs of factory A 
as a user or an attribute value of department. The Depart- 
ment of General Affairs 5ld of factory B connected to the 
network 52c of factory B and the Department of General 
Affairs 51a of laboratory connected to the laboratory net- 
work 52a can form, by limiting the services, the region 
having the properties different from that of the available 
region 53, namely the available region 54, that is, the logical 
network which can perform the same work in the Depart- 
ment of General Affairs 5i6, 51c of factory A, the Depart- 
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merit of General Affairs 5 Id of factory B and the Department control object. In the case of the rule by logical sum, a user 

of General Affairs 51a of laboratory because the service used (user 2) can make access to the network lc and network le 

for mutual information exchange between the Department of from the network 1c and network le and receive only the 

General Affairs Sib, 51c of factory A is fixed to the par- virtual terminal service. Also, in the case of the logical 

ticular services. 5 product, a user (user 2) can make access to the network lc 

By forming individual networks in different attribute and network le from the network lc and network le and 

values and properties, the network satisfying individual receive only the virtual terminal service, 

access policy and security policy can be constituted while A user (user 3) belongs to the Department of Planning and 

offering the transparent network environment. has the official position "General Manager". In the case of 

FIG. 20 shows a table 440 storing access control infor- 10 the rule by logical sum, a user (user 3) can make access to 

mation of official position, which are also user attributes, the network lb, network lc, network (Net-4) Id and network 

held in the repeater 2a. The access control table 440 of le from the network lb and network Id and receive only the 

official position held in the repeater describes, for each virtual terminal service. Also, in the case of the logical 

official position name 441, class of transmitting and desli- product, a user (user 3) can make access to the network lb, 

nation networks 442 indicating the accessible network is network lc, network Id and network (Net- 5) le from the 

range, remote destination 443 indicating the accessible des- network 16, network Id and can receive only the virtual 

tination network and available services 444. The class of terminal service. 

transmitting and destination networks 442 indicates the A user (user 4) belongs to the Department of Planning and 

accessible network range. Description "local" indicates that does not have any official position. In the case of the rule by 

only the network connected to the terminal unit in the 20 logical sum, a user (user 4) can make access to the network 

transmitting side may be used, while "remote" indicates that lb, network lc, network Id and network le from the 

the networks other than that connected to the terminal unit network lb and network Id and can receive only the virtual 

in the transmitting side can also be used. The remote terminal service. In the case of the rule by logical product, 

destination 443 is effective only when "remote" is set in the a user (user 4) can make access only in the network lb and 

transmitting and destination networks 442 and indicates the 25 network Id, 

accessible destination network. In this example, the official As explained above, the user in the user attribute table 

position "General Manager" can make access to the network 420, 430 or 440 can be denned as not only an individual but 

connected to the terminal unit of the transmitting side and to also a section, a group or a position, 

the network other than that connected to the terminal unit in Next, outline of the data repeating control executed in the 

the transmitting side and can make access to any network 30 communication procedures will be explained with reference 

and receives all services. The asterisk mark described in to FIG. 21. 

the table means access to any network is possible and any FIG. 21 shows the repeating route control table 450 

service can be received. The sign means that the item storing the data repeating route information held in the 

given this mark is not available. terminal unit 3b in the network 2 and the repeating route 

Relationship between the user access control table 420, 35 control table 451 storing the data repeating route informa- 

department access control table 430 and position access tion held in the terminal unit 2c. The tables 450, 451 storing 

control table 440 will be explained. A user (user 1) belongs the data repeating route information respectively have a 

to the Department of General Affairs and has the official network name describing field 4501 for designating the 

position "General Manager". A user (user 1) can make network which requires repeating and a repeater name 

access to the network la and network lb and receive the 40 describing field 4502 for designating a repeater used for 

service of only file transfer from the item 427a of user (user repeating to the network. 

1) in the user access control table 420. Next, from the item The network name describing field 4501 can use a nega- 

431 of the Department of General Affairs in the department live operator "-" for description of the part other than the 

access control table 430, a user (user 1) can make access to network name described. For instance, "-network 2" indi- 

the network la, network lb and receive the service of only 45 cates a "network other than the network 2". In the table 450, 

database access. Moreover, from the item 445a of position a record 4503 indicating "repeating to the network 1 is 

"General Manager" in the position access control table 440, performed by the repeater 2a'\ a record 4504 indicating 

the local and remote networks can be used and there is no "repeating to the network 3 is performed by the repeater 2b" 

limitation on the available services. and a record 4505 indicating "repeating to the network other 

The access control mechanism solves mismatching of 50 than the network 2 is performed by the repeater 2c" are 

these access control with any one of a rule of logical sum, registered respectively. 

a rule of logical product and a rule of attribute priority. For It is also possible to set that repealing to the network 4 and 

instance, in the case of the rule of logical sum, a user (user network 5 can be performed by the repeater 2c by sequen- 

1) can make access to the network la, network lb from the lially evaluating these records from the record registered 

network la, network lb and can receive the services of file 55 previously. In the same manner, in the table 451, a record 

transfer and database access. In the case of the rule of logical 4511 indicating "repeating to the network 1 is performed by 

sum, the asterisk mark "*" is excluded from the object. In the repeater 2a", a record 4512 indicating "repeating to the 

the case of the logical product, a user (user 1) can make network 3 is performed by the repeater 2b" and a record 

access to the network la, network lb from the network la 4505 indicating "repeating to the network 5 is performed by 

and network 1* but actually can make access within the 60 the repeater 2c" are registered. Description of network and 

network la and network lb because there is no receivable repeater in the table can be realized by designation with a 

service. Moreover, in the case of the rule of attribute priority, domain name and a host name in DNS or by designation 

the network (Net-1) la and network lb can be used the only with IP address and net mask. 

the file transfer service can be received by judging the In above embodiment, various attributes of user, access 

conditions only from user. 65 control information and user identification information are 

A user (user 2) has the official position "Section Chief. defined for each repeater and each apparatus for making 

In this case, department access control is excluded from the communication. Registration and renewal of these pieces of 
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information can be executed for each unit from an admin- 
istration terminal or by using a control unit for simulta- 
neously controlling the repeaters and terminal units for 
communication. 

Moreover, it is also possible to obtain the information by 5 
issuing an inquiry at the time of identifying a user and 
confirming contents of access control by previously regis- 
tering various attributes of user, access control information 
and user identification information to information server, 
etc. such as directory server. 10 

The basis virtual network system and apparatus of this 
system are explained above but erroneous connection can be 
prevented by executing mutual identification of terminal unit 
and repeater when the connection request (S10, S50) in the 
terminal unit control flowchart and the connection request is 
(S26) in the repeater control flowchart are issued. 

FIG. 22 shows an example of the mutual identification 
method in the communication procedure i. The identifica- 
tion information table 460 of the terminal unit 3b has an 
entry 4601 including ID of repeater 2c and a common key 20 
463. The identification information table 461 of the repeater 
2c has an entry 4611 including ID of terminal unit 3b and a 
common key 463 and an entry 4612 including ID of repeater 
2d and a common key 464. The identification information 
table 462 of repeater 2d has an entry 4621 including ID of 25 
repeater 2c and a common key 464. 

Utilization of the ISO/IEC9798, for example, using the 
common key explained above realizes mutual identification 
between the terminal unit 3b and repeater 2c and between 
the repeater 2c and repeater 2d, The communication data 30 
between adjacent apparatuses can also be encrypted depend- 
ing on the information used in common through the identi- 
fication process. 

FIG. 23 shows an example of the mutual identification 
system in the communication procedure 2. The identification 35 
information table 465 of terminal unit 3b has an entry 4651 
including ID of repeater 2c and a common key 468 and an 
entry 4652 including ID of repeater 2d and a common key 
469. The identification information table 466 of repeater 2c 
has an entry 4661 including ID of terminal unit 3b and a 40 
common key 468. The identification information table 467 
of repeater 2d has an entry 4671 including ID of terminal 
unit 3b and a common key 468. Utilization of the common 
key realizes mutual identification between the terminal unit 
3b and repeater 2c and mutual identification between the 45 
terminal unit 3b and repeater 2d. Moreover, the communi- 
cation data between the terminal unit 3b and the repeater 2d 
adjacent to the terminal unit 3e can also be encrypted 
depending on the information used in common through the 
identification process. 50 

When a plurality of repealers which enable repeating 
operation to the network exist as shown in FIG, 24, each 
repeater transmits, to the other repeater or terminal unit, the 
information of the network through which each repeater can 
repeats the data and the repeater or terminal unit can realize 55 
dynamic selection of route by writing the information 
received from the other repeater into the table 450 storing 
the route information. 

Moreover, dynamic route selection based on the priority 
can also be realized by adding the field 4506 indicating 60 
priority to the table 450 storing the route information as 
explained below. 

For example, when communication is made between the 
terminal unit 3b and the terminal unit 3a, the repeaters 2a> 
2c become the candidate repeaters for repeating operation. 65 
The repeaters 2a, 2c periodically transmit the numerical 
value information indicating the loading conditions thereof, 
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the priority field 4506 of records 4507, 4508 in the repeating 
route information storing table 450 are updated depending 
on the loading conditions of these repeaters, and the repeat- 
ers having higher priority are connected sequentially by 
referring to the field on the occasion of starting the com- 
munication. If connection is rejected, the repeater of the next 
priority is connected to realize dynamic route selection. 

FIG. 25 is a diagram for explaining an example of the 
communication infrastructure converting function in the 
virtual network structuring method and apparatus of this 
system. In this figure, 1101 designates a client computer; 

1102, a fire wall and repealing server; 1111, a communica- 
tion client program; 1121, a data repeating control program; 

1103, a server computer; 1131, a server program; 1104, a 
communication module corresponding to IP V4; 1105, a 
communication module corresponding to IP V6; 1106, an IP 
V4 network; 1107, an IP V6 network. The client computer 
1101 makes communication conforming to IP V4 protocol 
using the communication module 1104 corresponding to IP 
V4. Moreover, the server computer 1103 makes communi- 
cation conforming to IP V6 protocol using the communica- 
tion module 1105 corresponding to IP V4. 

Therefore, the client computer 1101 and server computer 
1103 cannot realize the direct communication. However, the 
communication between these client computer U0 1 and 
server computer 1103 can be realized by utilizing the data 
repeating control program 1121 in the fire wall and repeating 
server 1102 having the IP V4 communication module 1104 
and IP V6 communication module 1105. In FIG. 25, con- 
version between IP V4 and IP V6 has been conducted as an 
example of the communication infrastructure, but the exist- 
ing communication infrastructure can also be used by uti- 
lizing appropriate repeating program and repeating route 
table. 

FIG. 26 shows a table storing user application log 
obtained in the repeater. In the user application log table 470, 
a user name 471, a transmitting side terminal unit 472 used, 
a destination terminal unit 473 used, a service 474 which a 
user has received, condition 475 indicating start and end of 
service, accessibility 476 indicating that connection is 
accepted in the repeater in which log is collected and lime 
477 indicating start and end of service are described. 

As explained previously, the present invention assures the 
effect of offering a large scale network system for realizing 
communication having passed a fire wall by providing a 
means for exchanging the repeating route information 
between a plurality of fire walls (repeaters) and of offering 
a network system having higher security and operation 
flexibility by realizing access control based on computer 
users and applications. 

Although preferred embodiments of the present invention 
have been described and illustrated, it will be apparent to 
those skilled in the art that various modifications may be 
made without departing from the principles of the invention. 

We claim: 

1. A repeater for connecting two networks respectively 
connected to at least one terminal, comprising: 

means for receiving a connection request packet desig- 
nating a destination terminal from a transmission ter- 
minal; 

means for identifying a user by referring to a user infor- 
mation field stored in said connection request packet; 

means for controlling access depending on at least one 
attribute of said user in said connection request packet, 
and comprising: 

an access control table for storing correspondence 
between at least one attribute of at least one user and 
accessible range of said networks; and 
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means for checking said at least one attribute of said 
user in said connection request packet with said 
accessible range of said networks according to said 
access control tablet; 

means for transmitting said conneaion request packet to 5 
a next (stage) repeater provided to identify said user by 
referring to said user information field stored in said 
connection request packet; 

a repeating route control table for storing at least one 
correspondence between a first address area designated 10 
by excluding specified address area and an address of 
another device provided to transfer the data to said first 
address area, and for storing correspondence between a 
second address area including said destination terminal 
and an address of another repeater provided to transfer 15 
the data to said second address area; 

means for making a comparison between the destination 
terminal name field of said connection request packet 
and said destination terminal according to said repeat- 2Q 
ing route control table; and 

means for making a determination of the next (stage) 
repeater with reference to said repeating route control 
table based on said comparison. 

2. The repeater according to claim 1, wherein said means 2 s 
for controlling access executes access control by combining 
said attributes of said user in said access control table 
according to a predetermined rule. 

3. The repeater according to claim 2, wherein said 
attribute of said user in said access control table comprises 30 
at least one of a user name, an official position and a 
department. 

4. The repeater according to claim 3, further comprising: 
means for changing said attribute of said user in said 

access control table according to information received 35 
via said networks. 

5. A repeater for connecting two networks each being 
connected to at least one terminal, said repeater comprising: 

a repeating route control table for storing at least one 
correspondence between a first address area designated 40 
by excluding a specified address area and an address of 
another repeater provided to transfer the data to said 
first address area, and for storing correspondence 
between a second address area including said destina- 
tion terminal and an address of another repeater pro- 45 
vided to transfer the data to said second address area; 

means for receiving a connection request packet desig- 
nating a destination terminal from a transmission ter- 
minal; 

means for making a comparison between the destination 50 
terminal name field of said connection request packet 
and said destination terminal according to said repeat- 
ing route control table; 

means for making a determination of a next (stage) 55 
repeater with reference to said repeating route control 
table based on said comparison; and 

means for transmitting said conneaion request packet to 
said next (stage) repeater based on said determination. 

6. The repeater according to claim 5, further comprising: so 
means for changing contents of said repeating route 

control table according to information received via at 
least one of said networks. 

7. The repeater according to claim 6, wherein said means 
for changing changes said contents depending on a load 65 
condition, a fault condition or a designation of application 
running on said at least one terminal. 



8. A computer program stored on a storage medium, for 
repealing a communication, when said computer program is 
executed by a computer which conneas two networks each 
being connected to at least one terminal, said computer 
program causes said computer to perform the steps of: 

receiving a connection request packet designating a des- 
tination terminal of said at least one terminal from a 
transmission terminal of said at least one terminal; 

identifying a user by referring to a user information field 
stored in said connection request packet; 

controlling access depending on at least one attribute of 
said user in said conneaion request packet according to 
an access control table which stores correspondence 
between at least one attribute of at least one user and 
accessible range of said networks; and 

transmitting said connection request packet to a next 
(stage) repeater provided to identify said user by refer- 
ring to said user information field stored in said con- 
nection request packet. 

9. The computer program according to claim 8, wherein 
said controlling access step includes checking said at least 
one attribute of said user in said connection request packet 
with said accessible range of said networks according to said 
access control table. 

10. The computer program according to claim 9, further 
causing said computer to perform the steps of: 

making a comparison between the destination terminal 
name field of said connection request packet and the 
repeater name according to a repeating route control 
table which stores correspondence between an address 
area including said destination terminal and an address 
of another repeater provided to transfer the data to said 
address area; and 

determining a next (stage) repeater with reference to said 
repeating route control table based on said comparison. 

11. The computer program according to claim 9, wherein 
said controlling access step further includes combining said 
attributes of said user in said access control table according 
to a predetermined rule. 

12. The computer program according to claim 11, wherein 
said attribute of said user in said access control table 
comprises at least one of a user name, an official position and 
a department. 

13. The computer program according to claim 12, further 
causing said computer to perform the step of: 

changing said attribute of said user in said access control 
table according to information received via said net- 
works. 

14. A computer program stored on a storage medium, for 
repeating a communication, when said computer program is 
executed by a computer which conneas two networks each 
being connected to at least one terminal, said computer 
program causes said computer to perform the steps of: 

receiving a connection request packet designating a des- 
tination terminal of said at least one terminal from a 
transmission terminal of said at least one terminal; 

making a comparison between the destination terminal 
name field of said connection request packet and a 
repeater name according to a repeating route control 
table which stores correspondence between an address 
of said destination terminal and an address of another 
repeater provided to transfer the data to the address; 

making a determination of a next (stage) repeater with 
reference to said repeating route control table based on 
said comparison; and 
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transmitting a connection confirming packet to said des- 
tination terminal, a packet making said terminal trans- 
mit another connection request packet based on said 
determination. 

15. The computer program according to claim 14, further 5 
causing said computer to perform the step of: 

changing contents of said repeating route control table 
according to information received via at least one of 
said networks. 

16. The computer program according to claim 15, wherein 
said changing step further includes changing said contents 
depending on a load condition, a fault condition or a 
designation of application running on said at least one 
terminal. 15 

17. The computer program according to claim 16, wherein 
said storage medium is included in a server connected to said 
at least one terminal of said networks; and wherein said 
server transfers said computer program stored on said stor- 
age medium to said computer connected to said at least one 20 
terminal of said networks. 

18. A computer program according to claim 14 wherein 
said connection confirming packet includes a code making 
the transmission terminal judge whether the connection to 
said destination terminal is completed or not. 25 

19. A method for connecting two networks each being 
connected to at least one terminal, comprising the steps of: 

receiving a connection request packet designating a des- 
tination terminal from a transmission terminal; 30 

identifying a user by referring to a user information field 
stored in said connection request packet; 

controlling access depending on at least one attribute of 
said user in said connection request packet according to 
an access control table which stores correspondence 35 
between at least one attribute of at least one user and 
accessible range of said networks; and 

transmitting said connection request packet to a next 
(stage) repeater provided to identify said user by refer- 
ring to said user information field stored in said con- 40 
nection request packet. 

20. The method according lo claim 19, wherein said 
controlling access step includes checking said at least one 
attribute of said user in said connection request packet with 
said accessible range of said networks according to said 45 
access control table. 

21. The method according to claim 20, further causing 
said computer to perform the steps of: 

making a comparison between the destination terminal 5Q 
name field of said connection request packet and the 
repeater name according to a repeating route control 
table which stores correspondence between an address 
area including said destination terminal and an address 
of another repeater provided to transfer the data to said 5J 
address area; and 

making a determination of the next (stage) repeater with 
reference to said repealing route control table based on 
said comparison. 

22. The method according to claim 20, wherein said 60 
controlling access step further includes the sub step of: 

combining said attributes of said user in said access 
control table according to a predetermined rule. 

23. The method according lo claim 22, wherein said 
attribule of said user in said access control table comprises 65 
at least one of a user name, an official position and a 
department. 
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24. The method according to claim 23, further causing 
said computer to perform the step of: 

changing said attribute of said user in said access control 
table according to information received via said net- 
works. 

25. A method for connecting two networks each being 
connected lo at least one terminal, comprising the steps of: 

■ receiving a connection request packet designating a des- 
tination terminal from a transmission terminal; 

making a comparison between the destination terminal 
name field of said connection request packet and a 
repeater name according to a repeating route control 
table which stores correspondence between an address 
of said destination terminal and an address of another 
repeater provided to transfer the data to the address; 

making a determination of a next (stage) repeater with 
reference to said repeating route control table based on 
said comparison; and 

transmitting said connection request packet to said next 
(stage) repeater based on said determination. 

26. The method according to claim 25, further causing 
said computer to perform the step of: 

changing contents of said repeating route control table 
according to information received via at least one of 
said networks. 

27. The method according to claim 26, wherein said 
changing step further includes changing said contents 
depending on a load condition, a fault condition of said 
repeater or a designation of application running on said at 
least one terminal. 

28. A network system having at least two networks each 
being connected to at least one terminal, said network 
system comprising: 

a transmission terminal for transmitting a connection 
request packet designating a destination terminal and 
including at least one user attribute in a user informa- 
tion field; 

a repeater for connecting said networks to each other, said 
repeater comprising means for receiving said connec- 
tion request packet, and means for identifying said user 
by referring to said user information field stored in said 
connection request packet; 

a destination terminal for transmitting a connection con- 
firming packet as a response to said connection request 
packet, said destination terminal comprising: means for 
receiving said connection request packet, and means 
for identifying said user by referring to said user 
information field stored in said connection request 
packet, 

said transmission terminal confirming that each of said 
repeater and said destination terminal identifies said 
user and a communication route between said trans- 
mission terminal and said destination terminal is estab- 
lished. 

29. The network system according to claim 28, further 
comprising: 

means for controlling access depending on at least one 
attribute of said user in said connection request packet, 
wherein said means for controlling access comprises: 
an access control table for storing correspondence 
between at least one attribute of at least one user and 
accessible range of said networks; and means for 
checking said at least one attribute of said user in said 
connection request packet with said accessible range of 
said networks according to said access control table. 
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30. The network system according to claim 29, wherein 
said repeater further comprises: 

a repeating route control table for storing at least one 
correspondence between a first address area designated 
by excluding a specified address area and an address of 
another repeater provided to transfer the data to said 
first address area, and for storing correspondence 
between a second address area including said destina- 
tion terminal and an address of another repeater pro- 
vided to transfer the data to said second address area; 

means for making a comparison between the destination 
terminal name field of said connection request packet 
and the destination terminal name according to said 
repealing route control table; and 
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means for determining a next (stage) repeater with refer- 
ence to said repeating route control table based on said 
comparison. 

31. The network system according to claim 28, wherein 
5 said repeater further comprises means for transmitting said 

connection request packet to the next (stage) repeater based 
on access control information, said next (stage) repeater 
provided to identify said user referring to said user infor- 
mation field stored in said connection request packet. 

32. The network system according to claim 28, wherein 
said repeater further comprises means for transmitting said 
connection confirming packet to said transmission terminal 
based on access control information. 

***** 
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[57] ABSTRACT 

A multi- level network security system is disclosed for a 
computer host device coupled to at least one computer 
network. The system including a secure network interface 
Unit (SNIU) contained within a communications stack of the 
computer device that operates at a user layer communica- 
tions protocol. The SNIU communicates with other like 
SNIU devices on the network by establishing an association, 
thereby creating a global security perimeter for end-to-end 
communications and wherein the network may be individu- 
ally secure or no n -secure without compromising security of 
communicadons within the global security perimeter. The 
SNIU includes a host/network interface for receiving mes- 
sages sent between the computer device and network. The 
interface operative to convert the received messages to and 
from a format utilized by the network. A message parser for 
determining whether the association already exists with 
another SNIU device. A session manager coupled to said 
network interface for identifying and verifying the computer 
device requesting access to said network. The session man- 
ager also for transmitting messages received from the com- 
puter device when the message parser determines the asso- 
ciation already exists. An association manager coupled to 
the host/network interface for establishing an association 
with other like SNIU devices when the message parser 
determines the association does not exist. 

20 Claims, 4 Drawing Sheets 
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SYSTEM AND METHOD FOR PROVIDING 
MULTI-LEVEL SECURITY IN COMPUTER 
DEVICES UTILIZED WITH NON-SECURE 
NETWORKS 

RELATED APPLICATIONS 

The Assignee herein, ITT Corporation, is the record 
owner of co-pending U.S. application Ser. No, 08/270,398 to 
Boyle et al., entitled APPARATUS AND METHOD FOR 
PROVIDING NETWORK SECURITY, filed Jul. 5, 1994 
now U.S. Pal. No. 5,577,209 

FIELD OF THE INVENTION 

The present invention relates in general lo secure and 
multi-level secure (MLS) networks and in particular to a 
system and method for providing security and multi-level 
security for computer devices utilized in non-secure net- 
works. 

BACKGROUND OF THE INVENTION 

Multi -level secure (MLS) networks provide a means of 
transmitting data of different classification levels (i.e. 
Unclassified, Confidential, Secret and Top Secret) over the 
same physical network. To be secure, the network must 
provide the following security functions: data integrity 
protection, separation of data types, access control, authen- 
tication and user identification and accountability. 

Data integrity protection ensures that data sent to a 
terminal is not modified enroute. Header information and 
security level are also protected against uninvited modifi- 
cation. Data integrity protection can be performed by check 
sum routines or through transformation of data, which 
includes private key encryption and public key encryption. 

Separation of data types controls the ability of a user to 
send or receive certain types of data. Data types can include 
voice, video, E-Mail, etc. For instance, a host might not be 
able to handle video data, and, therefore, the separation 
function would prevent the host from receiving video data. 

Access control restricts communication to and from a 
host. In rule based access control, access is determined by 
the system assigned security attributes. For instance, only a 
user having Secret or Top Secret security clearance might be 
allowed access to classified information. In identity based 
access control, access is determined by user-defined 
attributes. For instance, access may be denied if the user is 
not identified as an authorized participant on a particular 
project For control of network assets, a user may be denied 
access to certain elements of the network. For instance, a 
user might be denied access to a modern, or to a data link, 
or to communication on a path from one address to another 
address. 

Identification of a user can be accomplished by a unique 
name, password, retina scan, smart card or even a key for the 
host. Accountability ensures that a specific user is account- 
able for particular actions. Once a user establishes a network 
connection, it may be desirable that the user's activities be 
audited such that a "trail" is created. If the user's actions do 
not conform to a set of norms, the connection may be 
terminated. 

Currently, there are three general approaches to providing 
security for a network: trusted networks, trusted hosts with 
trusted protocols, and encryption devices. The trusted net- 
work provides security by placing security measures within 
the configuration of the network. In general, the trusted 
network requires that existing protocols and, in some cases, 
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physical elements be replaced with secure systems. In the 
Boeing MLS Lan, for instance, the backbone cabling is 
replaced by optical fiber and all access to the backbone is 
mediated by security devices. In the Vferdix VS LAN, similar 
5 security devices are used to interface to the network, and the 
network uses encryption instead of fiber optics to protect the 
security of information transmitted between devices. 
VSLAN is limited to users on a local area network (LAN) 
as is the Boeing MLS Lan. 

10 Trusted hosts are host computers that provide security for 
a network by reviewing and controlling the transmission of 
all data on the network. For example, the U.S. National 
Security Agency (NSA) has initiated a program called 
Secure Data Network System (SDNS) which seeks to imple- 

15 ment a secure protocol for trusted hosts. In order to imple- 
ment this approach, the installed base of existing host 
computers must be upgraded to run the secure protocol. 
Such systems operate at the Network or Transport Layers 
(Layers 3 or 4) of the Open Systems Interconnection (OSI) 

20 model, r 

Encryption devices are used in a network environment to 
protect the confidentiality of information. They may also be 
used for separation of data types or classification levels. 
Packet encryptors or end-to-end encryption (EEE) devices, 
for instance, utilize different keys and labels in protocol 
headers to assure the protection of data. However, these 
protocols lack user accountability since they do not identify 
which user of the host is using the network, nor are they 
capable of preventing certain users from accessing the 
network. EEE devices typically operate at the Network 
Layer (Layer 3) of the OSI model. There is a government 
effort to develop cryptographic protocols which operate at 
other protocol layers. 

35 An area of growing concern in network security is the use 
of computer devices in non-secure networks. Such computer 
devices often include valuable information, which may be 
lost or stolen due to these computers being accessed through 
the non-secured network. In light of this problem, a number 

40 of related products have been developed. The products 
developed include Raptor Eagle, Raptor Remote, Entrust, 
Secret Agent and Veil. Although, these products serve the 
same purpose, a number of different approaches have been 
utilized. For example, Raptor Eagle, Raptor Remote, and 

45 Veil implement these products as software instantiations. 
While Entrust and Secret Agent utilize hardware crypto- 
graphic components. Additionally, Raptor products are also 
application independent. 
A problem with the above described products is that none 

50 are based upon the use of highly trusted software. Veil is an 
off-line encryption utility, which cannot prevent the inad- 
vertent release of non-encrypted information. While Raptor 
Eagle and Raptor Remote are based on software instantia- 
tions and thus cannot be verified at the same level of 

5S assurance. Secret Agent and Entrust while hardware based 
are dependent upon the development of integration software 
for specific applications. 

It is therefore, an objective of the present invention, to 
provide a multi-level security system that is readily adapt- 

60 able to computer devices which provides an adequate level 
of security assurances. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a network 
65 security apparatus and method for a network comprises a 
secure network interface unit (SNIU) coupled between host 
computer or user computer unit, which may be non-secure. 
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and a network (i.e. a SNIU can be placed between two 
networks), which may be non-secure. When an SNIU is 
implemented at each computer unit to be secured on the 
network, a global security perimeter is provided for ensuring 
security policy enforcement, controlled communication 
release, controlled communication flow, and secure session 
protocols through each computer unit interface. 

In a preferred embodiment, the SNIU is configured to 
process a defined trusted session protocol (TSP) and perform 
the core functions of host/network interface by utilizing an 
association manager, session manager and data sealer. The 
user/service interface function performs a standard commu- 
nications stack function by handling all of the standard 
communications data translation between the Physical Data 
Link and Network protocol layers (i.e. layers one thru three). 
The host/network interface does not require the same level 
of trust as the rest of SNIU's software. This allows this 
software to be logically and physically separated from the 
rest of the software without effecting the underlying security 
of the system as a whole. The association manager functions 
include host computer and peer SNIU identification, audit, 
association setup and termination and maintenance of the 
sealer keys generated for the association between the two 
peer SNIUs. The session manager functions include sealing, 
verifying message authentication codes, audit and enforcing 
a security on each datagram passed thru the SNIU. 

A software SNIU is also disclosed contained within a 
communications stack of a portable computer device oper- 
ating at a user layer communications protocol. The software 
SNIU contains the association and session managers as 
previously described, but not a host/network interface as the 
function is performed by the communications stack of the 
host computer. The SNIU is capable of communicating with 
other like SNIU devices creating a global security perimeter 
for end-to-end communications and wherein the network 
may be individually secure or non-secure without compro- 
mising security of communications within the global secu- 
rity perimeter. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic diagram of an MLS network system 
in accordance with the present invention; 

FIG. 2 is a block diagram of the software SNIU installed 
in a computer host in accordance with the present invention; 

FIG. 3 is a data flow diagram for the software SNIU in 
accordance with the present invention; 

FIG. 4 is a table showing the format for the Address 
Resolution Protocol and Reverse Address Resolution Pro- 
tocol messages in accordance with the present invention; 

FIG. 5 is a table showing the data structure for a token of 
the Association Table in accordance with the present inven- 
tion; and 

FIG. 6 is a table showing the data structure of a token for 
the Sym_Key Table in accordance with the present inven- 
tion. 

DETAILED DESCRIPTION 

The present invention is directed to a secure network 
interface unit (SNIU), which is utilized to control commu- 
nications between a user such as a computer host and a 
network at a "session layer" of interconnection which occurs 
when a user on the network is identified and a communica- 
tion session is to commence. For example, the industry- 
standard Open Systems Interconnection (OSI) model, 
defines seven layers of a network connection: (1) physical; 
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(2) data link; (3) network; (4) transport; (5) session; (6) 
presentation; and (7) application. In the present invention, 
the network security measures are implemented at the Ses- 
sion Layer 5. The placement of security at the Session Layer 
5 allows existing network assets and existing network proto- 
cols at the Transport Layer 4 and lower to continue to be 
used, thereby avoiding the need to replace an installed 
network base for the implementation of the multi-level 
security system. The connected host or user equipment and 
the network backbone are therefore not required to be secure 
(trusted). Conventionally, OSI network applications employ 
CO" IT X.215 which is a non-secure session layer protocol. 
None of the prior multi-level security systems employ the 
security measures described herein in the Session Layer. 
15 The SNIU according to the present invention can be ' 
configured in a number of different embodiments depending 
on the particular physical locations and forms of implemen- 
tation. These embodiments include a stand alone hardware 
SNIU and a software SNIU. 
20 The hardware embodiment of the SNIU is implemented 
solely as a stand alone hardware device. Such a configura- 
tion is desirable, since the stand alone SNIU is highly 
trusted. The stand alone SNIU is configured to be inserted 
between existing hosts and a network. The SNIU is trans- 
25 parent to the host, and any legacy system or application 
software running on the host. The stand alone SNIU pro- 
vides protection for any host connected to an IP based 
network. There is no requirement that the attached host 
computers run a trusted operating system. The stand alone 
30 SNIU provides a trusted boundary between the protected 
hosts and the unprotected network. Protected means that the 
connection is with another known SNIU (a unique digital 
signature identifies the SNIU), the messages are confidential 
(encrypted) and unaltered (cryptographic residues validate 
3 5 the packet). 

The software embodiment of the SNIU is implemented 
solely as a software function resident in and executed from 
the host machine. Such a configuration is desirable, since the 
5 software SNIU is designed to be installed in existing 
40 portable computers, which avoids tbe additional cost of 
additional hardware required by a stand alone hardware 
SNIU. The software SNIU provides the same network 
security features as the stand alone SNIU when the host 
computer is connected to home enterprise's network. The 
45 software SNIU also extends that same level of security 
across the Internet (or any other unprotected network) when 
the user is on the road and is remotely communicating with 
the enterprise network or other remotely located computer 
devices including a similar software SNIU. 
so The software SNIU provides all of the functionality and 
security of the stand alone SNIU as well as complete 
operability with these devices. The software comprising the 
software SNIU is based on the same software utilized in the 
stand alone hardware SNIU. The user of the software SNIU 
55 assumes an acceptable risk in exchange for not requiring 
additional hardware required by a stand alone SNIU, which 
cannot be circumvented or corrupted via attacks from origi- 
nating from external hardware. By providing reasonable 
software protection (not allowing unauthorized personal 
60 physical access), and software protection (anti-virus 
protection), a software SNIU can be utilized providing tbe 
user with an acceptable level of risk. If the user is confident 
that the software comprising the software SNIU is not 
circumvented or modified, then he can enjoy the same 
65 degree of confidence as the user of a stand alone device. 
Referring to FIG. 1, there is shown an example of a 
Multi-Level Security (MLS) System in accordance with the 
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present invention. This system 10 incorporates the various once contained one or more objects to be secured from 
embodiments of the SNIUs in order to provide MLS for unauthorized access. To be secured, reused, and assigned to 
computer networks such as the Internet. For example, the a new subject, storage media must contain no residual data 
guard devices 14,16 which are hardware embodiments of the f rom the object previously contained in the media. Object 
SNIU are coupled between computer networks 34,3638 5 reuse protection may be implemented by port reuse 
providing inter-network security. Additional guard devices protection, session reuse protection, dialog reuse protection, 
12,18 are coupled between users such as computer hosts and/or association reuse protection. 
283032 and the respective networks 30,3234. The soft- Labeling requires that each object within the network be 
ware embodiment of the SNIU are implemented as com- labeled as to its current level of operation, classification, or 
panions within computer hosts 24,26, which provides net- io accreditation range. Labeling may be provided in the fol- 
work security without requiring additional hardware. The lowing ways: user session security labeling, wherein each 
auditors 20,22 are also hardware SNIUs which are coring- user session is labeled as to the classification of the infor- 
med to communicate directly with the other SNIUs to log mation being passed over it; dialog labeling, wherein each 
audit events and potentially signal alarms. The above dialog is labeled as to the classification and type of the 
described system 10 enables secured and non-secured users 15 information being passed over it; and host accreditation 
such as a web site 40 to communicate with each other range, wherein each host with access to the secured network 
without the danger of compromising security. is given an accreditation range, and information passing to 
During operation, the SNIUs included in the above or from the host must be labeled within the accreditation 
described system 10 communicate with each other thereby range. 

creating a global security perimeter for end-to-end commu- 20 Identification is a process that enables recognition of an 
nications and wherein the network may be individually entity by the system, generally by the use of unique user 
secure or non-secure without compromising security of names. Authentication is a process of verifying the identity 
communications within the global security perimeter. The of a user, device, or other entity in the network. These 
SNIUs are capable of passing digital data, voice and video processes may be implemented in the following ways: user 
traffic so as to provide the full functionality required for a 25 identification; user authentication; dialog source 
Trusted Session Protocol (TSP). The TSP uses the facilities authentication, wherein the source of all communication 
of the lower level protocols to transmit data across the paths is authenticated at the receiving SNIU before corn- 
networks. To this end, and to provide flexibility, the spe- munication is allowed; SNIU source authentication, wherein 
cializcd network interface SNIU is designed to allow cou- the source SNIU is authenticated before data is accepted for 
pling of the TSP with existing (non-secure) equipment and 30 delivery; and 

underlying network. administrator authentication, wherein an administrator is 

Security System Policies authenticated before being allowed access to the Security 

The SNIU devices in accordance with the present inven- Manager functions, 

tion may implement a number of security policies suitable to An audit trail provides a chronological record of system 

the circumstances of a given network environment. The 35 activities that is sufficient to enable the review of an 

major policy areas are: discretionary access control; man- operation, a procedure, or an event. An audit trail may be 

datory access control; object reuse; labeling; identification implemented via a user session audit, a dialog audit, an 

and authentication; audit; denial of service detection; data association audit, an administrator audit, and/or a variance 

type integrity; cascading control; and covert channel use detection, wherein audit tra Us are analyzed for variance from 

detection. 40 normal procedures. 

Discretionary access control is a means of restricting Denial of service is defined as any action or series of 

access to objects (data files) based on the identity (and need actions that prevent any part of a system from functioning in 

to know) of the user, process, and/or group to which the user accordance with its intended purpose. This includes any 

belongs. It may be used to control access to user interface action that causes unauthorized destruction, modification, or 

ports based on the identity of the user. For a single-user 45 delay of service. The detection of a denial of service may be 

computer unit, this mechanism may be implemented in the implemented for the following condition: user session auto- 

SNIU, whereas for a multi-user host, the DAC control may matic termination, such as when unauthorized access has 

be implemented at the host machine. Discretionary access been attempted; user machine denial of service detection, 

control may also be implemented as discretionary dialog such as detection of a lack of activity on a user machine; 

addressing, wherein the addressing of all communications 50 dialog denial of service detection; association denial of 

originated by a user is defined, and for user discretionary service detection, such as detection of a lack of activity 

access denial wherein a user may refuse to accept a com- between SNIUs; and/or data corruption detection, such as 

munication from another user. when an incorrect acceptance level is exceeded. 

Mandatory access control is a means of restricting access Covert channel use is a communications channel that 

to objects based on the sensitivity (as represented by a 55 allows two cooperating processes to transfer information in 

classification label) of the information contained in the a manner that violates the system's security policies. Detec- 

objects, and the formal authorization (i.e., clearance) of the tion of covert channel use may be implemented, for 

user to access information of such sensitivity. For example, example, by delay of service detection, such as monitoring 

it may be implemented as dialog lattice-based access for unusual delays in message reception, or dialog sequence 

control, wherein access requires a correct classification 60 error detection, such as monitoring for message block 

level, integrity level, and compartment authorization, dialog sequence errors, 

data-type access control, wherein correct data type authori- Details Of the Software SNIU 

zation is required for access, and cascade protection, Referring to FIG. 2, a block diagram of the software SNIU 
wherein controls are provided to prevent unauthorized installed in a computer host is shown. The software SNIU 44 
access by cascading user access levels in the network. 65 ■ is implemented as a software function within a host corn- 
Object reuse is the reassignment and reuse of a storage puter 42. The SNIU 42 interfaces with the communications 
medium (e.g., page frame, disk sector, magnetic tape) that slack of the host computer 58 in order to send and receive 
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messages over the Ethernet or token ring cable 74. The 
communications stack 58 is a typical OSI model including 
a physical 72, data link layer 70, network layer 68, transport 
layer 66, session layer 64, presentation layer 62 and appli- 
cation layer 60. The network layer 68 includes an ARP/ 
RARP module which is utilized to process Address Reso- 
lution Protocol (ARP) and Reverse Address Resolution 
Protocol (RARP). 

As can be seen from FIG. 2, the SNIU 44 is installed 
between the network and data link layers of the communi- 
cations stack 68,70, which enables it to be transparent to the 
other high order software. 

The main modules of the SNIU include a Host/Network 
Interface 46, Session Manager 48, Trusted Computing Base 
50, Audit Manager 52, Association Manager 54 and Fortezza 
API 56. 

The primary data structures included in the SNIU are the 
Association Table, Sym_Key Table, Certificate Table, Wait- 
ing Queue and Schedule Table. These data structures are 
described later in the description of the protocol. 

The Host/Network Interface 46 provides the interfacing 
between the SNIU 44 and communications stack 58. The 
Fortezza API 56 is a driver for the card reader 76 included 
in the host computer 42. The card reader 76 is adapted to 
receive a Fortezza card which is a PCMCI card configured 
to perform integrity and authenticating functions. The 
Fortezza card performs the integrity function by encrypting 
messages leaving the SNIU 44 and decrypting incoming 
messages. The authentication function is accomplished by 
the Fortezza card generating and reading digital signatures 
which are unique to each SNIU. The Fortezza card includes 
a private key to generate the digital signature and a public 
key to read the signatures. The other SNIU modules will be 
described in conjunction with data flow diagram of FIG. 3. 

Referring to FIG. 3, there is shown a data flow diagram 
for the software SNIU. When the host computer communi- 
cates with another computer over a network, the communi- 
cations protocol stack within the computer processes the o 
data to be transmitted. If a user on the computer is trans- 
mitting a file to another computer, the user may select the file 
to send by interacting with application layers software. The 
display which the user sees is controlled by presentation 
layer software. Session layer software checks the users 
permission codes to determine if the user has access to the 
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security policy. The TCB 50 includes a Scheduler module 
50A and a Message Parser SOB. The Scheduler 50A is 
utilized to control the flow of datagrams within the SNIU. 
The scheduler 50A provides timing for incoming datagrams 
5 and temporarily stores these datagrams in a buffer if earlier 
ones are being processed. 

The Message Parser SOB is tbc first module in the TCB 
which processes an IP datagram received from the host 
computer. The Message Parser SOB checks the Association 
10 Table 76 and determines whether or not an association 
already exists for sending the datagram to its destination. If 
no association exists, the datagram is stored on the Waiting 
Queue and the Association Manager 54 is called to establish 
an association between this SNIU and the SNIU closest to 
is the destination host. If an association does exist, the Session 
Manager 48 is called to encrypt the datagram, check security 
rules, and send the encrypted Protected User Datagram 
(PUD) to the peer SNIU. 

When the Association Manager 54 is called, it prepares 
two messages to initiate the association establishment pro- 
cess. The first message is an Association Request Message 
which contains the originating host computer level and this 
SNIU's certificate (containing it's public signature key). 
This message is passed to the Fortezza API 56 which 
controls the Fortezza card which signs the message with this 
SNIU's private signature key. The second message is an 
I CMP Echo Request message which will be returned to this 
SNIU if it is received by the destination host. Both messages 
are passes to the network-side Host/Network Interface Mod- 
ule 46 to be transmitted to the destination host. 

When a SNIU receives messages, the messages are first 
processed by the SNIU's receiving port's Host/Network 
Interface 46 which reassembles the messages and passes 
them to the trusted software. The Message Parser module 
SOB passes the Association Request Message to the Asso- 
ciation Manager 54 module and deletes the ICMP Echo 
Request message. The Association Manager 54 passes the 
message to the Fortezza API 56 which verifies the digital 
signature. If not valid, the Audit Manager 52 is called to 
generate an Audit Event Message to log the error. If the 
signature is OK, the Association Manager 54 saves a copy 
of the received Association Request Message in the Waiting 
Queue, adds this SNIU's certificate to the message, calls the 
Fortezza API 56 to sign the message, generates a new ICMP 
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Datagrams containing blocks of file data and determines that 
the transmitted file data is properly received and acknowl- 
edged or is re-transmitted. 

The Host/Network interface 46 is utilized to intercept the 
data packets transmitted between the network and data link 
layers 68,70. The interface 46 is utilized to format the data 
packets into an appropriate format depending on whether the 
data packet is incoming or out going. The interface 46 
accomplishes this by removing the hardware address header 
when it receives a data packet and re-applies the same 
header when the packet is released (even if the underlying IP 
address header was changed). Since the interface in the 
software SNIU 46 does not handle ARP and RARP message 
for the host computer, it can be smaller than the one utilized 
in the hardware SNIU. As previously described, the ARP/ 
RARP module included in the network layer 68 performs 
this function. 

When the untrusted Host/Network Interface 46 completes 
re-assembling an IP datagram from a host computer, the 
datagram is passed to the Trusted Computing Base 50 (TCB) 
of the SNIU for processing. The TCB 50 is the collection of 
hardware and software which can be trusted to enforce the 
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Host/Network Interface module 46 to transmit the messages 
to the destination host. If the messages are received by any 
other SNIU's before reaching the destination host, this 
process is repeated by each SNIU. 

If the destination host computer does not contain the 
Companion SNIU software, the host's communications pro- 
tocol stack software automatically converts the ICMP Echo 
Request message to an ICMP Echo Reply and returns it to 
the SNIU which sent it. However, the destination host does 
not contain any software which can process the Association 
Request Message; so it is ignored (i.e., deleted). 

If the destination host computer does contain Companion 
SNIU software, the host's data link layer software converts 
the stream of bits from the physical layer into packets which 
are passed to the Companion's Host/Network Interface 
module 46. The hardware address headers are stripped off of 
the packets and saved; and the packets are re-assembled into 
IP datagrams which are passed to the Message Parser SOB. 
The ICMP Echo Request message is ignored; and the 
Association Request Message is passed to the Fortezza API 
56 to have the signature verified. If valid, the message is 
passed to the Association Manager module 54 which saves 
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the originating host and SNIU data and generates an Asso- layer where the re-assembled datagram is passed to the 

ciation Grant Message. This message contains the SNIU's IP Session Manager 48. The source IP address is to identify the 

address (which is the same as the destination host's), the release key which is shared with the previous SNIU. The 

SNIU's certificate, the host's security level, and scaler keys Fortezza API 56 uses the release key to verify the message 
for the originating SNIU and the previous intermediate 5 authorization code, if not valid, the Session Manager 48 

SNIU (if there was one). The sealer keys (a.k.a. Message deletes the datagram and calls the Audit Manager 52 to 

Encryption Keys) are explained elsewhere. generate an Audit Event Message. If the code is valid, it 

The Fortezza API 56 is then called to sign the message removes the code from the datagram, and uses the destina- 

which is passed to the Host/Network Interface module 46. tion IP address to identify the release key shared with the 
The Association Grant Message is converted from an IP 10 next SNIU. The Fortezza API 56 generates a new message 

datagram to network packets and passed back to the host's authorization code. The Session Manager 48 appends the 

hardware packet drivers (n the data link layer) for transmis- new code and passes the datagram to the opposite port's 

sion back to the originating host. Host Network Interface module. 

Any intermediate SNIU's which receive the Association When the peer SNIU (i.e., the destination IP address) 
Gram Message process the message up through the com- is received the PUD and it has been reassembled into a 

munications stack protocol layers to the network layer which datagram, the Message Parser 50B passes the datagram to 

calls the Message Parser SOB to process the message. The the Session Manager 48. The source IP address is used lo 

signature on the message is verified by the Fortezza API 56 identify the corresponding association key. The Fortezza 

and audited via the Audit Manager 52 if not valid. API 56 decrypts the original user datagram. The Session 
Otherwise, the validated message is processed by the Asso- 20 Manager checks the message authorization code and the 

ciation Manager 54 module which removes and saves one of security levels of the source and destination hosts. If the 

the sealer keys (a.k.a. a release key) which will be used by code is valid (i.e., the message was not modified during 

this SNIU and the previous SNIU (which generated the key) transmission over the network) and the security levels 

to authenticate PUD messages exchanged via this associa- match, the decrypted datagram is passed to the Host/ 

tion in the future. The Fortezza API 56 is called to generate 25 Network Interface 46 to be released to the destination host 

and wrap another sealer key to be shared with the next SNIU If either is not correct, the Audit Manager 52 is called, 

in the association path. The new key and this SNIU's The following is a discussion of the protocol which is 

certificate arc appended to the message. The Ftirtezza API 56 applicable to both the hardware and software embodiments 

aligns the message. The Host/Network Interface 46 trans- of the SNIU: 

mils the message on its way back to the originating SNIU. 30 Address Resolution Messages 

The originating SNIU re-assembles the Association Grant Address Resolution Protocol (ARP) allows a SNIU to 
Message via the physical, data link 70, and network layers locate a host or another SNIU, given its IP address. As 
68 as previously described. The signature is validated and previously discussed, this function is performed by the 
audited if necessary. If valid, the Association Manager 56 host/network interface in the hardware SNIUs and by the 
uses the Fortezza API to unwrap the sealer key(s). If two 35 computer host itself for the software SNIUs. The SNIU 
keys are in the received message, the bottom key is a release broadcasts an ARP Request message which contains its 
key to be shared with the first intermediate SNIU; and the hardware and IP addresses and the IP address of the target 
top key is an association key to be shared with the peer SNIU host. The target host (or other SNIU) returns to the request- 
(which granted the association). If there is only one key, it ing host an ARP Response message which contains the 
is the association key which is shared with the peer SNIU; 40 hardware address of the target host (or other SNIU). 
and the association path does not contain any intermediate Reverse Address Resolution Protocol (RARP) allows a 
SNIUs. Once the keys are stored and the Association Table SNIU which only knows its hardware address to obtain an 
76 is updated, the association is established and the Session IP address from the network. The host broadcasts a RARP 
Manager 48 is called to transmit the original user datagram Response which contains its hardware address, and a server 
which was stored in the waitmg Queue prior to issuing the 45 on the network returns a RARP Response containing an IP 
Association Request Message. address assigned to the requester's hardware address. All 
The Session Manager 48 enforces the security policy, ARP and RARP messages have the same format and are 
determines whether IP datagrams received from host com- contained within the frame data area of a single Ethernet 
puters can be transmitted via the network to their destination frame (they are not IP datagrams). The format of the ARP 
host, encapsulated these user datagrams in PUDs using the 50 and RARP messages is shown in the Table of FIG. 4. 
sealer keys for the appropriate association. The security Referring to FIG. 4, the HARDWARE TYPE is set to 
policy is enforced by comparing the security levels of the 0001 hex to indicate Ethernet. The PROTOCOLTYPE is set 
host and destination. If the security levels are the same, the to 0800 hex lo indicate IP addresses. The HLEN (hardware 
Session Manager checks the Association Table and identi- address length) is set to 06 hex bytes, while the PLEN 
fied the appropriate peer SNIU and sealer key(s). The user 55 (protocol address length) is set to 04 hex bytes The OPERA- 
datagram is encrypted by the Fortezza API 56 using the TION is set 0001 hex for an ARP request message, 0002 hex 
association key. If the association contains any intermediate for ARP response message, 0003 hex for an RARP request 
SNIUs, the Fortezza API 56 calculates a message authori- message or 0004 hex for RARP response message The 
zation code using the release key. The Session Manager 48 SENDER'S HA contains the sender's 48 bit Ethernet hard- 
creates a PUD addressed from this SNIU to the peer SNIU, 60 ware address, while the SENDER'S IP contains the sender's 
encloses the encrypted user datagram, appends the message 32 bit IP address. The TARGET'S HA contains the target's 
authorization code (if any), and passes the new datagram to 48 bit Ethernet hardware address, while the TARGET'S IP 
the Host/Network Interface module 46 on the network-side contains the sender's 32 bit IP address, 
of the SNIU. The datagram is broken into packets and When a SNIU broadcasts a request message it fills in all 
transmuted as prev,ously described. 65 of the data and the target's hardware address field is set to 
If an intermediate SNIU receives the PUD, the data is 000000 hex for an ARP message. If the message is a RARP 
passed through the data link layer software 70 to the network then the sender's a D d target's IP address fields are set to 
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0000 hex. When the target machine responds, it fills in the port B. If releasable, the TCB inserts it into port B's address 
missing address and changes the operation field to indicate list. Secondly, the TCB checks the Anticipated Message list 
a response message. During an ARP, the target machine for port B and determines whether the ARP Response was 
swaps the sender's and target's addresses so that the sender's due to a proxy ARP Request made for a request originally 
address fields contains its addresses and the target's address 5 received on port B. If the SENDER'S IP matches an entry 

fields contains ihe original requesting host's addresses. in the Anticipated Message List and the message is releas- 

During a RARP, the server stores its addresses in the able to port B, the TCB signals port B's untrusted software 

sender's address fields and returns the response to t he to create a proxy ARP Response message identical to the 

original sender's hardware address. Anticipated Message and then removes the message from 

When a SNIU receives a message, it performs the fol- 10 the Anticipated Message list for port B. 

lowing processes: RARP Request— If a RARP Request message is received 

ARP Request — If an ARP Re quest message is received on a SNIU's port A, the untrusted software in port A's 

on a SNIU's port A, the untrusted software in port A's memory segment checks a flag to determine if the SNIU was 

memory segment determines if the sender's IP address is in initialized to act as a RARP server for the network attached 

port A's ARP cache. If not, it creates a new entry in the ARP is to port A. If not, the received message is ignored. Otherwise, 

cache and inserts the sender's hardware and IP addresses. the untrusted software passes the RARP Request to the TCB. 

Otherwise, the sender's hardware address is copied into the The TCB determines whether the RARP Request can be 

entry (overwriting any previous address) and packets (if released to port B. If releasable, it creates a proxy RARP 

any) waiting to be sent to the sender's IP address are Request message copying the TARGET'S HA from the 

transmitted. If the target's IP address is in port A's address 20 received message and inserting port B's addresses in the 

list (i.e., a List of IP addresses which are accessed from port SENDER'S HA and IP fields. Then the TCB passe the proxy 

B), the untrusted software returns an ARP Response mes- RARP Request message to port B's untrusted software for 

sage swapping the SENDER'S and TARGET'S addresses broadcast and creates an Anticipated message in the form of 

and inserting port A's Ethernet hardware address into the a proxy RARP Response message. The TCB copies the 

SENDER'S HA field. In either case, the untrusted software 25 original TARGETS HA, inserts port A's hardware address in 

passes the ARP Request Trusted Computing Base (TCB). the SENDER'S HA and saves it in the Anticipated Message 

The TCB checks port B's address list for the SENDER'S list for port A. 
IP. If the SENDER'S IP is not in port B's address list, the RARP Response— If a RARP Response message is 
TCB determines whether the SENDER'S IP is releasable to received on a SNIU's port A, the untrusted software in port 
port B. If releasable, the TCB inserts SENDER'S IP into port 30 A's memory segment determines if the sender's IP address 
B's address list. Secondly, the TCB determines whether a is in port A's ARP cache. If not, it creates a new entry in the 
proxy ARP Request should be broadcast from port B. If an ARP cache and inserts the sender's hardware and IP 
ARP Response message was not returned by port A and the addresses. Otherwise, the sender's hardware address is cop- 
target's IP address is not in port A's ARP cache, then the ied into the entry (overwriting any previous address) and 
sender's IP is releasable to port B. Thus, causing the TCB to 35 packets (if any) waiting to be sent to the sender's IP address 
create a proxy ARP Request message. The TCB inserts port are transmitted. Finally, the untrusted software inserts the 
B's hardware and IP addresses in the SENDER'S address TARGET'S IP into pen A's address list and passes the 
fields, copies the target's IP address from the original ARP RARP Response to the TCB. 

Request into the TARGET'S IP field and then signals port The TCB checks port B's address List for the SENDER'S 

B's untrusted software to broadcast the message. 40 IP. If the SENDER'S IP is not in pen B's address list, the 

Each time the TCB releases a proxy ARP Request, it TCB determines whether the SENDER'S IP is releasable to 

creates an Anticipated Message in the form of a proxy ARP port B. If releasable, the TCB inserts it into port B's address 

Response message. This proxy ARP Response message list. Secondly, toe TCB determines whether the TARGETS 

contains the original sender's addresses in the TARGETS IP is releasable to port B. If releasable, the TCB creates a 

fields, the target's IP address in the SENDER'S IP field and 45 new entry in port B's ARP cache and inserts the TARGETS 

port A's hardware address is the SENDER'S HA field. This HA and IP. The TCB uses the TARGETS HA to find the 

message is saved in the Anticipated Message list for port A appropriate proxy RARP Response message in port B's 

and will be released to port A's untrusted software for Anticipated Message List and copies the TARGETS IP and 

transmission, if the anticipated ARP Response message is SENDER'S IP into the Anticipated message. Then the TCB 

received on port B, Note that whether this message is 50 signals port B's untrusted software to create a proxy RARP 

released may involve the TCB modulating ARP Requests Response message identical to the Anticipated Message, and 

from a high network to a low network in order not to exceed removes the message from the Anticipated Message list for 

the 100 bits per second covert channel bandwidth require- port B. 

mcnt - Association Establishment Messages 

ARP Response— If an ARP Response message is received 55 SNIUs establish associations in order to authenticate each 

on a SNIU's port A, the untrusted software in port A's other, exchange security parameters, and establish trusted 

memory segment determines if the sender's IP address is in sessions for communication. The SNIUs utilize a standard 

port A's ARP cache. If not, it creates a new entry in the ARP ICMP Echo Request message to request an association and 

cache and inserts the sender's hardware and IP addresses. an ICMP Echo Reply message to grant an association. 

Otherwise, the sender's hardware address is copied into the 60 When a host behind a SNIU attempts to communicate 

entry (overwriting any previous address) and packets (if with someone else over the network, the SNIU stores the 

any) waiting to be sent to the sender's IP address are datagram from the host in a waiting queue and transmits an 

transmitted. Finally, the untrusted software passes the ARP ICMP Echo Request to the intended destination. This mes- 

Response to the TCB. sage is used to identify other SNIU units in the communi- 

The TCB checks port B's address list for the SENDER'S 65 cations path and to carry the originating SNIU's security 

IP. If the SENDER'S IP is not in port B's address list, the parameters. The SNIU inserts the originating host's security 

TCB determines whether the SENDER'S IP is releasable to level, appends its certificate and then signs the message. 
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Eacb SNIU unil which receives this message authenticates gram (i.e., a response lo a previous datagram from the lower 

the message, saves a copy of the previous SNIU's certificate, level host) was predicted by the SNIU which sent the 

appends its certificate, and signs the message before sending protected datagram. Therefore, this SNIU is assured that the 

it to the destination. classification of the received datagram is dominated by the 
The destination host returns an ICMP Echo Reply to the 5 lower Level destination host, so that the datagram is released 

originating SNIU. The first SNIU to receive this message is to the destination. If a SNIU receives a user datagram from 

the terminating SNIU (i.e., closest to the destination) in the a native host which would be a write-down lo the destination 

potential association's communications path. This SNIU host and no predicted datagram is found, the received 

determines if the association should be permitted (i.e. would datagram is erased and the attempted writedown is audited, 
not violate the security policy). If permitted, the SNIU 10 Message Processing Tables 

grants the association, generates an encryption key for the There are three tables which are used to process 

association, and encrypts the key using the originating in-coming and out-going messages including the Associa- 

SNIU's public key (from its certificate). If the Echo Request lion Table, the Symmetric Key Table(Sym_Key) and the 

message contained an intermediate SNIU's certificate, the Certificate Table. Each SNIU has to Association tables, one 
SNIU also generates a release key and encrypts it using the is for each port. Each entry contains data corresponding to a 

intermediate SNIU's public key. In either case, the SNIU particular source or destination IP address. The Sym_Key 

removes its and the originating SNIU's security parameters table contains data corresponding to a particular message 

and signatures from the ICMP Echo Reply, stores the encryption key (MEK) which could be used as a release key 

encrypted key(s), inserts the destination host's security or an association key. The Certificate table contains recently 
level, appends its certificate, signs the message and sends it 20 received certificates from other SNIU's. 

onto the originating SNIU. Each table consists of a linked list of tokens in which the 

Each intermediate SNIU (if any exist) which receives the data for an entry in the table is stored in a token. The tokens 

Echo Reply message authenticates the previous SNIU's for each table have a unique data structure and are linked 

signature, extracts the release key, generates a new release together in 'free* lists during initialization. When a new 

key for the next SNIU, encrypts the key using the public key 25 entry is made in one of the tables, a token is removed from 

(from the certificate saved from the Echo Request message) the free list for that table's tokens, the data for the new entry 

of the next SNIU, removes the previous intermediate is inserted in the appropriate fields of the token and the token 

SNIU's certificate and signature, appends its own certificate is linked at the top of the table. When an entry is removed 

and signature, and sends the message on the return path. from a table, the previous' and 'next* tokens arc linked, the 

When the originating SNIU receives the ICMP Echo Reply, 30 data fields in the token are cleared and the token is linked at 

it authenticates the message and extracts the key(s). the bottom of the appropriate free list. Whenever the data in 

Once the association is granted, the originating SNIU an entry is used, the token is removed from the table and 

fetches the originating host's datagram from the waiting relinked at the top of the table. In this way the oldest (i.e., 

queue and prepares to send it to the terminating SNIU in the least used) entry is at the bottom of the table, 

newly established association. The SNIU uses the associa- 35 If a new entry is needed and the free list is empty, the 

lion key to encrypt the datagram for privacy. The SNIU bottom token is removed from the table, the data fields are 

further stores the encrypted datagram and the encryption cleared, the new entry's data is inserted and the token is 

residue into a new datagram from the originating SNIU to linked at the top of the table. In addition, when a SNIU 

the terminating SNIU. If the association contains interme- removes the bottom (oldest unused) token in the Sym_Key 

diate SNIUs, the originating SNIU uses the release key to 40 Table, it also removes every token in the Association Table 

calculate a second encryption residue and appends it to the which pointed to the removed key. A SNIU does not send a 

datagram. Finally, the SNIU transmits the protected user Close Association Message when a certificate, key or Asso- 

datagram to the peer SNIU in the association. ciation Table entry is removed because many valid entries 

When the protected user datagram is received by an using the same association may still exist. The data structure 

intermediate SNIU (if any in the path), the intermediate 45 for a token of the Association Table is shown in the Table of 

SNIU fetches the release key corresponding to the previous FIG. 5. 

SNIU and uses the release key to validate the datagram. If Referring to FIG. 5, NEXT is a pointer to the next token 

valid, the SNIU removes the release key residue from the in the table or list. PREVIOUS is a pointer to the previous 

datagram and checks to determine whether there are more token in the table or list. IP ADDRESS is the IP address of 

intermediate SNIUs in the path before reaching the termi- 50 the source/destination, while PEER SNIU IP ADDRESS is 

nating SNIU. If another intermediate SNIU exists, the the address of the other terminating SNIU for the associa- 

release key corresponding to the next intermediate SNIU is tion. ASSOCIATION KEY POINTER points to the associa- 

used to calculate a new release residue which is appended to tion MEK in the Sym„Key table. RELEASE KEY 

the datagram. In either case, the datagram is sent on its way POINTER points to the release MEK in the Sym_Key table, 

out the opposite port from which it was received. 55 The ASSOC-TYPE is set to 0001 hex for 'pending', 0002 

When the terminating SNIU receives the protected user hex for *host'(i.e., the entry is for a host destination)', 0003 

datagram, it uses the association key corresponding to the hex for 'sniu'(i.e., the entry is for a SNIU destination)', 0004 

originating SNIU to decrypt and validate the datagram. If the hex for 'native host'(i.e., no peer SNIU) or 0005 hex for 

source and destination hosts are at the same security level 'audit catcher'. The RELKEY-TYPE is set to 0001 hex for 

(i.e., a write-equai situation), the decrypted datagram is sent 60 'in '(i.e., use to validate release key residue), 0002 hex for 

out the opposite port lo the destination host. If the source 'out'(i.e., use to add release key residue) or 0003 hex for 

host has a lower security level than the destination (i.e., a 'both'. SECURITY- LEVEL indicates the security level of 

write-up situation), the SNIU predicts the response from the the source/destination, while SPARE is an unused byte to. 

destination and saves it before sending the decrypted data- keep addressing on a 32-bit boundary, 

gram to the destination host. 6 5 Referring to FIG. 6, there is shown the data structure of 

If the source host has a higher security level than the a token for the Sym_Key Table according to the present 

destination (i.e., a write-down situation), the received data- invention. NEXT is a pointer to the next token in the table 
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or list, while PREVIOUS is a pointer to the previous token encrypt (i.e., wrap) the MEK. The key exchange algorithm 

in the table or list. DISTINGUISHED NAME is the 128 byte is designed so that only the sending and receiving SNIUs can 

name in certificate from the other SNIU using this key. MEK decrypt the MEK and use it The sender wraps the MEK for 

is tbc 12 byte wrapped key (association or release) shared transmission using the destination's public Key RA,RB 

with the another SNIU. IV is the 24 byte initialization vector 5 (which is always set -1) and tbc sender's private key. IVs 

associated with the MEK CERTIFICATE POINTER points which were generated with release keys are transmitted in 

to the other SNIU's certificate in the Certificate table. the clear with the wrapped MEK in the Association Grant 

INDEX is a Fortezza card key register index which indicates Message, while IVs which were generated with association 

if and where the key is loaded (1-9 are valid key register keys are ignored. The recipient unwraps the key using its 
indexes, while 0 indicate that the key is not loaded on the 10 private key RA,RB, and the sending SNIU's public key. 

Fortezza). SPARE is an unused byte to keep addressing on Once unwrapped, the safe exchange is complete, 

a 32- bit boundary. Each SNIU re-wraps the MEK using its storage key (Ks), 

Message Flag stores the MEK and the IV (if the MEK is a release key) in 

Any message (IP datagram) which is generated or modi- theSym_Key Table, stores the pointer to the MEK in the 
fied by a SNIU unit contains a Message Flag in the last four is Association Table and stores the DN (of the other SNIU 

bytes of the datagram. The first byte is the message type sharing this MEK) in the Sym_Key Table entry, 

field, the second byte is the message format field and the Using MEKs and IVs 

third and fourth bytes are the Flag. Note that all message Message Encryption Keys (MEKs) are used as association 

types are signed except for a Protected User Datagram and release keys to provide confidentiality, integrity and 
(PUD) which uses MEK residues for integrity and authen- 20 authentication of user datagrams during an association 

tication. between two SNIUs. IVs are used to initialize the feedback 

Waiting Que and Schedule Table loop in the Skipjack encryption algorithm for most modes of 

The Waiting Que is used to store IP datagrams for operation. Encrypting identical data using the same MEK, 

potential future processing based on an anticipated event. but different IVs, will produce different cipher text. In fact, 

For every entry made in the Waiting Que, a corresponding 25 the Fortezza card requires the user to generate a new IV for 

entry is made in the Schedule Table. The Schedule Table is each encryption event in order to assure that each message 

used to automatically process entries in the Waiting Queue looks different when encrypted. 

if they have not been processed within some predetermined When a SNIU encrypts a user datagram it first generates 

amount of time (i.e. the anticipated event does not occur). a new IV for the association key, encrypts the datagram, 

The Schedule Table entry contains a time-out field (which is 30 appends the encryption residue for integrity and authentica- 

set to the current time plus some reasonable delta represent- tion purposes, and appends the new IV. If the association 

ing the maximum waiting period) and a function pointer involves intermediate SNIUs, the SNIU performs a decrypt 

(which indicates which subroutine should be called if time operation on the newly encrypted datagram, residue and IV 

expires before the Waiting Queue entry is processed). The The decrypt operation uses the release key and release Key 

Schedule Table is checked in the main executive loop of the 35 IV. The release key IV is never changed since the encrypted 

TCB, expired entries are removed and the corresponding data is always guaranteed to be unique even if the original 

datagrams in the Waiting Queue are processed by the datagram is not. The release key residue is appended to the 

designated subroutine. protected user datagram. The completed protected user 

For example, when a SNIU receives a user datagram from datagram is then transmitted, 

a native host which is destined for another host for which 40 Received Message Processing 

there is no existing association, the SNIU stores the user When a SNIU receives an IP datagram, it checks the 

datagram in the Waiting Queue and transmits an Association destination address in the header and determines if it is the 

Request message. When the Association Grant message is intended recipient. Then, the SNIU checks the last four bytes 

received, the user datagram is removed from the Waiting of the IP datagram for the Message flag and determines the 

Queue, the corresponding Schedule Table entry is deleted, as type and format of the received message, 

the user datagram is encrypted and sent to the peer SNIU of Destination SNIU Message Processing 

the association. If an Association Grant message is never When a SNIU receives an IP datagram which is addressed 

received, the Schedule Table entry expires which calls a to it, the message should be one of the following messages: 

subroutine to delete the user datagram from the Waiting an Audit Event, Audit Catcher list, Audit Mask, Association 

Q ucuc - 50 Close, Association Request, Association Grant, Association 

Another example is when the SNIU sends an Audit Event Denial, Association Unknown, Protected User Datagram, 
message to an Audit Catcher. The transmitted datagram is Receipt and Certificate Revocation List. If it is not, the SNIU 
stored in the Waiting Queue. When the Receipt message is audits the event. The only exceptions are ICMP datagrams 
received from the Audit Catcher, the original Audit Event which are processed by the receiving port's untrusted soft- 
datagram is removed from the Waiting Queue and the 55 ware and not passed to the trusted computing base, 
corresponding Schedule Table entry is deleted. If the Sched- Audit Event— If the SNIU is not configured to be an Audit 
ule Table entry expires, the designated subroutine is called Catcher, it will audit the event sending the source IP address 
which re-transmits Audit Event message stored in the Wait- of the received message to its primary Audit catcher, 
ing Queue and a new entry is made in the Schedule Table. If the SNIU is configured to be an Audit Catcher, it 
Generating and Exchanging MEKs 60 verifies the signature on the message, increments its 

Message Encryption Keys (MEKS) are generated during received audit event sequence number, generates a time 

the association establishment process (previously described) stamp, and prints the sequence number, lime stamp, source 

and are exchanged via the Association Grant Message. IP address, and ASCII character string from the message. 

When a SNIU generates an MEK, it simultaneously gener- Once the event has been recorded, the Audit catcher SNIU 

ates an initialization vector (IV). 65 generates a Receipt Message (copies the audit event counter 

When a SNIU exchanges an MEK with another SNIU, it from the received message and inserts it in the message 

generates a random number, RA, which is required to number field), sends it, and checks the receiving port's 
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Association Table for an entry for the source of the received 
message. If an entry does not exist (i.e., this was the first 
communication from the source SNIU). the Audit Catcher 
makes an entry, marks the association type as *sniu\ and 
sends the SNIU the current audit mask- 5 
Audit Catcher List — The SNIU verifies the signature on . 
the message, stores the new list of Audit catchers in the 
Configuration table, generates a receipt message, and audits 
the event. 

Audit Mask — the SNIU verifies the signature on the 10 
message, stores the new audit mask in the Configuration 
Table, generates a Receipt Message, and audits the event (in 
case someone else other than the Audit Catcher is distrib- 
uting new audit masks). In addition, if the receiving SNIU 
is an Audit Catcher, it distributes the new audit mask to is 
every destination in the Association Table with an associa- 
tion type of 'sniu\ 

Association Close — When a SNIU receives a valid pro- 
tected User Datagram, but cannot find the destination's 
Association Table entry, it sends an Association close mes- 20 
sage back to the originating SNIU and audits the event. The 
originating SNIU verifies the signature on the received 
Association Close Message, extracts the original destination 
host's IP, removes the host's entry from its Association 
Table and audits the event. It does not remove the peer 25 
SNIU's entry nor entries from the Sym_Key table as they 
might be supporting other associations. 

Association Request — This message can only be received 
by a SNIU which originally transmitted it as an I CMP echo 
request to some unknown destination which converted it to 30 
an Echo reply and returned it to the originator without 
encountering another SNIU. Therefore, the SNIU uses the 
source IP address to find the destination's entry in the 
Association Table, changes the association type from 'pend- 
ing* to 'native host*, sets the security level to that port's 35 
security level, finds the original host's user datagram in the 
Waiting Queue, removes the corresponding entry from the 
Schedule table, and compares the source and destination 
security levels to determine if the user program can be sent 
to the destination. If the comparison indicates a write-up 40 
situation, the SNIU generates and saves an anticipated 
message and releases the original datagram to the destina- 
tion port. If a write down situation, the SNIU determines if 
the data gram was predicted and sends the anticipated 
message or audits as previously described. If a write equal, 45 
the datagram is released to the destination port. This proce- 
dure is repealed for each entry in the Waiting Queue which 
is intended- for the same destination. Association Grant — 
The SNIU verifies the signature in the datagram and updates 
the receiving port's Association Table entries for the host 50 
destination and peer SNIU. The SNIU finds the entry for the 
destination host, changes the association type from 'pend- 
ing' to 'host', copies the peer SNIU's IP, extracts and 
unwraps the association MEK (and release MEK if needed), 
stores the re- wrapped key(s) in the Sym_Key table, marks 55 
the release key type as 'out' (if a release key exists), copies 
the destination host's security level, and determines if an 
entry exists for the peer SNIU. If not, the SNIU creates a 
new entry for the peer SNIU, copies the association and 
release key pointers and release key type from the destina- 60 
lion host's entry, and marks the association type as 'sniu'. 

Once receiving the port's Association Table has been 
updated, the SNIU finds the original hosts user datagram in 
the waiting Queue, removes the corresponding entry from 
the Schedule table, and compares the source and destination 65 
security levels to determine if the user datagram can be sent 
to the destination. If the source's security level is dominated 



by (i.e., less than or equal to) the destination's security level, 
the SNIU creates a Protected user Datagram (PUD). The 
SNIU sets the destination to the peer SNIU's IP, sets the 
protocol type to indicate a SNIU Message, uses the asso- 
ciation key to encrypt the entire received datagram, inserts 
the ciphertext and IV, appends the association residue, 
generates and inserts a release residue (if the destination 
host's Association Table entry contains a pointer to a release 
key), appends the appropriate SNIU Message Flag, and 
sends the datagram. If the source host is not dominated by 
the destination (i.e., potential write down, the attempted 
write down is audited. This procedure is repeated for each 
entry in the Waiting Queue which is intended for the same 
destination. 

Association Unknown — A SNIU sends an Association 
Unknown message (and generates audit notices) when a 
protected user datagram is received and a corresponding 
Association Table entry does not exist. The message is sent 
back to the source SNIU and contains the destination 
SNIU's IP address. When a SNIU receives an Association 
Unknown Message, it deletes every entry in the Association 
Table in which the peer SNIU address matches the returned 
destination SNIU IP. Subsequent user datagrams from the 
same host sent to the same destination will initiate an 
Association Request to re-establish the association. Any 
SNIU involved in establishing an association for which it 
already has keys (association and/or release keys) will 
suggest the same key as originally used. 

Protected User Datagram — the SNIU uses the source IP to 
find the appropriate entry in the receiving port's Association 
Table and retrieve the association key to decrypt and validate 
the received datagram. If the decryption residue docs not 
match, the even is audited. Otherwise, the SNIU uses the 
destination host's IP to find the appropriate entry in the 
opposite port's Association Table, retrieves the destination 
host's security level, and compares it to the security level in 
the received datagram. If a write-up situation, the SNIU 
generates an anticipated message. However, regardless of 
the relative security levels, the decrypted and validated user 
datagram is sent to the destination host. 

If a terminating SNIU receives a PUD and validates the 
residue but cannot deliver the user datagram because it 
cannot find the destination host in the Association Table, 
then the SNIU returns an Association close message to the 
originating SNIU (containing the destination host's IP) and 
audits the event. 

Receipt — A Receipt message is sent by an Audit catcher 
to a SNIU for Audit Catcher Request and Audit Event 
messages. The SNIU uses the message number in the 
received datagram to locate the saved copy of the original 
message in the Waiting Queue and remove it and the 
corresponding Schedule Table entry. If the original message 
was an Audit Catcher Request Message, the SNIU locates 
the Association Table entry for the Audit catcher and 
changes the association type from 'pending* to 'audit 
catcher'. If time expires in the Schedule Table entry before 
the Receipt Message is received, the SNIU will retransmit 
the original message, [f no receipt is received after TBD 
attempts, the SNIU will switch to the next Audit Catcher in 
the list. If all Audit Catchers are attempted without success, 
the SNIU will check a configuration parameter to determine 
whether to continue without audit or halt, 

SNIUs issue Receipt messages to Audit catchers for Audit 
Catcher List, Audit Mask, and Certificate Revocation List 
messages. When an Audit Catcher receives a receipt, it uses 
the returned message number to remove the copy of the 
message from the Waiting Queue and the corresponding 
Schedule table entry. 
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Certificate Revocation List— if a Certificate revocation 
List (CRL) is received, the SNIU returns a receipt to the 
source and checks the Sym_Key Table for any keys which 
were received from (or sent to) another SNIU with a revoked 
certificate, the SNIU deletes the certificate from the Certifi- 
cate Table (if it is still there), deletes the Sym_Key Table 
entry, and deletes every entry in the Association Table which 
pointed to the key. Note that deleting a table entry means to 
unlink the token from the table, clear the token's memory, 
and re-link the token in the token's free list. 
Non-Destination SNTU Message Processing 

When a SNIU receives an IP datagram which is not 
addressed to it, the message should be one of the following 
types of Dragonfly formatted messages. If it is not, the SNIU 
will assume the IP datagram is from a native host. 

Audit Event— The SNIU verifies the signature on the 
message and releases the message out the opposite pen 
Audit Catcher List— The SNIU verifies the signature 
on the message and releases the message out the 
opposite port. 

Audit Mask— The SNIU verifies the signature on the 
message and releases the message out the opposite port. 

Association Close— The SNIU verifies the signature on 
the message and releases the message out the opposite 
port. 

Association Request — When a SNIU receives an Asso- 
ciation Request it first checks the IP header to deter- 
mine if the datagram is an ICMP Echo Request or an 
ICMP Echo Reply. 
If it is an ICMP Echo Request, the SNIU validates the 
signature at the bottom of the message and checks the 
receiving port's Association Table for an entry with the 
originating SNIU's IP address. If the receiving SNIU cannot 
find an entry, it creates one, marks the association type as 
'pending', stores the previous SNIU's certificate in the 
Certificate Table (if it wasn't already there), updates the 
Sym_Key Table entry for the Distinguished Name (DN), 
and stores the pointer to the Sym_Key Table entry in the 
release key pointer field in the Association Table entry. If the 
previous SNIU was an intermediate SNIU (i.e., the Message 
Formal field of the SNIU Message Flag is 'Signed Type 2'), 
this SNIU marks the release key type field as 'out' and 
removes the previous SNIU's certificate and signature. In 
either case, this SNIU appends its certificate and signature 
and sends the message out the other port. It does not make 
any entry in the out-going port's Association Table. 

If it is an ICMP Echo Reply, this SNIU is the terminating 
SNIU which must generate the Association Grant Message. 
Before the SNIU can validate the received message, it must 
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datagram header). If the release key type is marked 'out* or 
'both', then the association path contains at least one inter- 
mediate SNIU; therefore, the SNIU extracts the peer SNIU's 
certificate from the datagram, stores it in the Certificate 
Table, stores the pointer to the certificate and the DN in a 
Sym_Key Table entry, and stores the pointer to the Sym_ 
Key Table entry in -the association key pointer field of the 
Association Table entry. If there aren't any intermediate 
SNIUs, the pointer in the release key pointer field is copied 
to the association key pointer field; and the release key 
pointer field is cleared. In either case the association type is 
marked as *sniu\ The third Association Table entry is for the 
originating host. It's IP and security level are in the data 
portion of the received datagram. The security level is 
copied into the entry, the association type is marked as 
'host', and the rest of the data is copied from the peer SNIU 
entry. Finally, the SNIU generates the association key (and 
if necessary, the release key) and stores the key(s) in the 
Sym_Key Table entry(s). 

Once the Association Table entries are updated, an Asso- 
ciation Grant Message is generated. The SNIU uses the peer 
(i.e., originating) SNIU's IP for the destination, uses the 
original destination host's IP for the source, and marks the 
protocol and type fields to indicate an ICMP Echo Reply. 
The SNIU inserts its IP address, its certificate, its host's 
security level, the association key data (wrapped key and 
RA), and if necessary, the release key data (the wrapped key, 
RA and IV). The SNIU Message Flag is inserted at the 
bottom marking the type as Association Grant and the 
format as Signed Type 1 to indicate only one certificate. The 
message is signed and sent. 

Association Grant — The SNIU validates the signature at 
the bottom of the received datagram and, if not correct, 
audits the event. Otherwise, since it is not the destination, 
the SNIU is an intermediate SNIU somewhere in the path 
between the two peer SNIUS. The SNIU creates an entry (if 
one doesn't already exist) in the receiving port's Association 
Table for the IP of the terminating SNIU which granted the 
association (note that the terminating SNIU's IP is not in the 
header of the received datagram, rather it is in the data area), 
marks the association type as 'sniu', marks the release key 
type as 4 in'(if the format is 'Signed Type 1') or 'both' (if the 
format is * Signed Type 2'), extracts the release key data (i.e., 
the wrapped MEK, RA and IV), unwraps and stores the 
release key in the Sym_Key Table, stores the release key IV 
in the same Sym_Key Table entry, stores the pointer to the 
release key in the Association Table, stores the certificate in 
the Certificate Table, and stores the pointer to the certificate 
and the DN in the Sym_Key Table entry. 
Next, the SNIU uses the destination IP address in the 



reconstruct the message to match the form it was in when the 50 header of the received Association Grant Message to find the 
?^}}L t l&acd . il bcforc thc destination host converted the destination's entry in the opposite port's Association Table. 

If the association type is 'pending', the SNIU uses the 



ICMP Echo Request into an ICMP Echo Reply. Therefore, 
the SNIU exchanges thc source and destination IP addresses 
in the datagram header and changes the type field in the 
ICMP header from a request (8) to a reply (0). Then the 
SNIU validates the signature at the bottom of the newly 
reconstructed message using its own public key. If the 
signature cannot be validated, the event is audited. 

If the ICMP Echo Reply is valid, the SNIU creates or 
updates three Association Table entries. First, it creates an 
entry (if it doesn't already exist) in the receiving port's 
Association Table for the original destination host (using the 
destination IP from the modified datagram header), marks 
the association type as 'native host' and stores the receiving 
port's security level in the security level field. Second, it 
updates the entry in the opposite port's Association Table for 
the peer SNIU (using the source IP from the modified 



release key pointer to fetch the saved certificate of the next 
SNIU, generates release key data (an MEK, RA, and IV), 
55 stores the wrapped MEK and IV in the Sym_Key Table 
entry, and changes the association type to 'sniu'. If the 
association type is 'NULL', the SNIU changes it to 'in'; 
otherwise, it is marked as 'both'. 

Finally, the SNIU rebuilds the Association Grant Message 
60 to send on to the destination. The SNIU copies the received 
datagram up to and including the association key data and 
the certificate of the SNIU which originated the Association 
Grant Message, inserts its certificate and the release key 
data, and signs and sends the datagram. 
65 Association Unknown— The SNIU verifies the signature 
on the message and releases the message out the opposite 
port 
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Protected User Datagram— The SNIU uses the source IP 
address to Mod the appropriate entry in the receiving port's 
Association Table, fetches the release key, and verifies the 
release key residue. If the release residue is Dot correct the 
datagram is deleted and the event audited. Otherwise, the 5 
SNIU uses the destination IP address to find the appropriate 
entry in the opposite port's Association Tabic, fetches the 
release key, generates the new release residue, overwrites 
the old release residue, and sends the datagram on to the 
destination. 

Receipt — The SNIU verifies the signature of the message 10 
and releases the message out the opposite port. 

Certificate Revocation List — The SNIU verifies the sig- 
nature on the message and releases the message out the 
opposite port. 

Native Host Message— When a SNIU receives a user 15 
datagram from a native host, the SNIU creates an entry (if 
one doesn't already exist) in the receiving port's Association 
Table for the source host's IP, marks the association type as 

* native host', sets the security level to the receiving port's 
security level, and checks the opposite port's Association 20 
Table for the destination's IP address. 

If an entry does not already exist for the destination, the 
SNIU creates a new entry, marks the association type as 

* pending', stores the received datagram in the Waiting 
Queue, makes a corresponding entry in the Schedule Table, 25 
creates an Association Request Message and sends it. 

If an Association Table entry exists for the destination and 
the association type is 'pending', the SNIU stores the 
received datagram in the Waiting Queue, linking it to other 
datagrams for the same destination. 30 

If an Association Table entry exists for the destination and 
the association type is 'host', the SNIU compares the source 
host's security level to the destination host's security level. 
If the source's security level is dominated by (i.e., less than 



What is claimed is: 

1. A multi-level network security system for a computer 
host device coupled to at least one computer network, 
comprising: 

a secure network interface Unit (SNIU) contained within 
a communications stack of said computer device that 
operates at a user layer communications protocol, said 
SNIU communicates with other like SNIU devices on 
said network by establishing an association, thereby 
creating a global security perimeter for end-to-end 
communications and wherein said network may be 
individually secure or non-secure without compromis- 
ing security of communications within said global 
security perimeter, comprising: 
a host/network interface for receiving messages sent 
between said computer device and said network, said 
interface operative to convert said received messages 
to and from a formal utilized by said network; 
a message parser for determining whether said asso- 
ciation already exists with another SNIU device; 
a session manager coupled to said network interface for 
identifying and verifying said computer device 
requesting access to said network, said session man- 
ager also for transmitting said messages received 
from said computer device when said message parser 
determines said association already exists; and 
an association manager coupled to said host/network 
interface for establishing an association with other 
like SNIU devices when said message parser deter- 
mines said association docs not exist. 

2. The system of claim 1, wherein said SNIU is contained 
within said communications stack between a Network layer 
and a Data Link layer. 

3. The system of claim 1, which further includes means 



or equal to) the destination, the SNIU creates a Protected 35 coupled to SNIU for performing both encryption and 

User Datagram (PUD). The SNIU sets the destination to the decryption functions. 

peer SNIU's IP, sets the protocol type to indicate a SNIU 4. The system of claim 3, which further includes means 
Message, uses the association key to encrypt the entire for generating and writing cryptographic residues for out- 
received datagram, inserts the cipher text and IV, appends going messages and validating cryptographic residues for 
the association residue, generates and inserts a release 40 incoming residues. 

residue (if the Association Table entry contains a pointer to 5. The system of claim 1, wherein said session manager 
a release Key), appends the appropriate Dragonfly Message protects the security communications between said corn- 
Flag, and sends the datagram. If the source host is not puter device and said network by implementing a security 
dominated by the destination (i.e., a potential write down), policy selected from a group consisting of discretionary 
the SNIU determines if this datagram was anticipated. If a 45 access control, mandatory access control, labeling, denial of 



matching datagram was predicted the anticipated datagram 
is transformed into a PUD (as described above) and sent. If 
an anticipated message is not found, the attempted write- 
down is audited. 

If an Association Table entry exists for the destination and 
the association type is any other bona fide type, i.e., 'native 
host', 'sniu\ or 'audit catcher', the SNIU compares the 
source and destination port's security levels to determine if 
the datagram can be allowed to proceed. If the comparison 



service detection, data type integrity, cascading control and 
covert channel use detection. 

6. The system of claim 1, wherein said SNIU further 
includes means for performing a defined trusted session 

50 layer protocol (TSP), said TSP constituting said user layer 
communications protocol. 

7. The system of claim 1, wherein said SNIUs exchange 
security parameters during said association. 

8. The system of claim 1, wherein said SNIU further 



indicates a write-up situation, the SNIU generates and saves 55 includes a scheduler coupled between said host/network and 
an anticipated message and releases the original datagram to 
the destination port. If a write-down situation, the SNIU 
determines if the datagram was predicted and sends the 
anticipated message or audits as previously described. If a 
write-equal, the datagram is released to the destination port. 60 

It is to be will be understood that the embodiments o 
described herein are merely exemplary of the principles of 
the invention, and that a person skilled in the art may make 
many variations and modifications without departing from 
the spirit and scope of the invention. All such variations and 65 
modifications are intended to be included within the scope of 
the invention as defined in the appended claims. 



said message parser for controlling the flow of said data 
within said SNIU. 

9. The system of claim 1, wherein said Association 
manager generates two messages in order to establish said 
association. 

10. The system of claim 1, wherein said SNIU further 
includes an audit manager coupled to said association man- 
ager for generating audit event messages when a message is 
received with an invalid authorization code. 

11. A method of providing a multi-level network security 
system for a portable computer device coupled to at least one 
computer network, comprising: 
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placing a secure network interface Unit (SN1U) within a 
communications stack of said computer device that 
operates at a user layer communications protocol, said 
SNIU communicates with other like SNIU devices on 
said network by establishing an association, thereby 5 
creating a global security perimeter for end-to-end 
communications and wherein said network may be 
individually secure or non-secure without compromis- 
ing security of communications within said global 
security perimeter, said SNIU performing a plurality of 10 
security functions including: 

receiving said messages sent between said computer 
device and said network; 

converting said received messages to and from a format 
utilized by said network; 15 

identifying and verifying said computer device request- 
ing access to said network at the session level; 

determining whether said association already exists 
with another SNIU device; 

transmitting said messages received from said com- 20 
puter device when said association already exists; 
and 

establishing an association with other like SNIU 
devices when said association does not exist. 
12. The method of claim U, wherein said SNIU is placed 25 
within said communications stack between a Network layer 
and a Data Link layer. 



13. The method of claim 11, which further includes 
encrypting outgoing messages and decrypting incoming 
messages of said SNIU. 

14. The method of claim 13, which further includes 
generating and writing cryptographic residues for outgoing 
messages and validating cryptographic residues for incom- 
ing residues. 

15. The method of claim 11, wherein said SNIU protects 
the security communications between said computer device 
and said network by implementing a security policy selected 
from a group consisting of discretionary access control, 
mandatory access control, labeling, denial of service 
detection, data type integrity, cascading control and covert 
channel use detection. 

16. The method of claim 11, wherein said SNIU further 
performs a denned trusted session layer protocol (TSP), said 
TSP constituting said user layer communications protocol. 

17. The method of claim 11, which further includes 
generating an audit trail. 

18. The method of claim 11, which further includes 
temporarily storing said received messages from said com- 
puter device when said association does not exist 

19. The method of claim 11, wherein said association is 
established by generating two messages. 

20. The method of claim 1, wherein said SNIUs exchange 
security parameters during said association. 
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METHOD AND APPARATUS FOR POLICY- 
BASED ALARM NOTIFICATION IN A 
DISTRIBUTED NETWORK MANAGEMENT 
ENVIRONMENT 

5 

FIELD OF THE INVENTION 

The present invention relates to alarm notification in a 
communications network and more specifically to a method 
and apparatus for receiving alarms from multiple network 
management servers, applying policies to those alarms and 1C 
forwarding the alarms that conform to the policies to one or 
more network management applications. 

BACKGROUND OF THE INVENTION 

Spectrum™ is a model-based network management 15 
system, sold by Cabletron Systems, Inc., Rochester, N.H. for 
maintaining and processing information pertaining to the 
condition of a communications network and providing the 
same to a user. For example, Spectrum™ will periodically 
poll a network device to request information, such as the 20 
number of packets sent on the network in a given time and 
the number of errors that occurred. If the error rate is above 
a predetermined limit, an error alarm is logged in the 
Spectrum™ database, an alarm sent to the user interface to 
notify the network manager, and a message is sent to shut off 25 
the corresponding network device. 

Alternatively, if no response was received from the net- 
work device when it was polled, the reason for the loss of 
contact should be determined so that appropriate action, 30 
such as a service call, can be taken. In a network 
environment, loss of contact with a network device may be 
due to failure of that network device or to failure of another 
network device that is involved in the transmission of a 
message. 35 

In many prior art network management systems, the 
network administrator was typically provided with a list of 
possible causes of a fault and was required to isolate the fault 
based on his experience and knowledge of the network. In 
Spectrum™, the system itself isolates network defaults 40 
using a technique known as Status Suppression. Spectrum™ 
maintains a database of models for each network device. 
When contact between a model and its corresponding net- 
work device is lost, the model sets a fault status and initiates 
the fault isolation technique. The model (first model) which 45 
lost contact with its corresponding network device (first 
network device) determines whether adjacent models have 
lost contact with their corresponding neiwork devices; adja- 
cent network devices are defined as those which are directly 
connected to a specified network device. If adjacent models 50 
cannot contact the corresponding network devices, then the 
first network device cannot be the cause of the fault, and its 
fault status in the first model will be overriden. By sup- 
pressing the fault status of the network devices wbicb are 
determined not to be defective, the defective network device 55 
can be identified. Once the fault has been isolated, the 
condition of the defective device can be updated in the 
Spectrum™ database, a control message can be sent shutting 
off the defective device, and the network administrator can 
be notified via the user interface. gg 

Spectrum™*s associated SpectroGRAPH™ user inter- 
face provides a graphical view into the network models. An 
alarm log view, shown in FIG. 1, includes an area 120 for the 
listing of current alarms, and an area 122 for displaying 
information pertaining to a selected alarm. The user may 65 
click on a particular alarm in the listing of current alarms to 
obtain more information. A multi-function icon 124 repre- 
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senting the network device having a fault is displayed in area 
122, with one or more text fields 126 and 128 which provide 
information to the user regarding the cause of the alarm and 
the status of the device. By clicking on specified areas of the 
icon 124, the user can obtain further information regarding 
the device for which an alarm is registered. 

Another method for fault management in large commu- 
nications networks is to use a so-called "trouble-ticketing" 
system. This system provides a number of tools that can be 
used by network users, administrators, and repair and main- 
tenance personnel. The basic data structure, a " trouble - 
ticket", has a number of fields in which a user can enter data 
describing the parameters of an observed network fault. A 
trouble-ticket filled out by a user may then be transmitted by, 
for example, an electronic mail system to maintenance and 
repair personnel. A trouble -ticket describing a current net- 
work fault that needs to be acted on is called "an outstanding 
trouble-ticket". When the network fault has been corrected, 
the solution to the problem, typically called a "resolution" is 
entered into an appropriate data field in the trouble-ticket 
and the trouble-ticket is said to be completed. The system 
provides for storage of completed trouble-tickets in memory 
and thus a library of such tickets is created, allowing users, 
administrators, and maintenance and repair personnel to 
refer to the stored completed trouble-tickets for assistance in 
determining solutions to future network faults. An example 
of a trouble -ticketing system is the ACTION REQUEST 
system, developed by Remedy Corporation, Mountain View, 
Calif., and sold by Cabletron Systems, Inc., Rochester, N.H. 

ARS Gateway™ is a network management application 
sold by Cabletron Systems, Inc. which receives fault infor- 
mation from the Spectrum™ system and automatically 
generates a trouble -ticket that may be processed by the 
ACTION REQUEST system. This system is further 
described in copending and commonly owned U.S. Ser. No. 
08/023,972 filed Feb. 26, 1993 by Lundy Lewis, and entitled 
"Method and Apparatus For Resolving Faults In Commu- 
nications Networks," and which is hereby incorporated by 
reference in its entirety. 

The Spectrum™ system is described in U.S. Pat. No. 
5,261,044 issued Nov. 9, 1993 to Roger Dev et al., which is 
hereby incorporated by reference in its entirety. The Spec- 
trum™ network management system is commercially avail- 
able and also described in various user manuals and litera- 
ture available from Cabletron Systems, Inc., Rochester, N.H. 

Other network management platforms and applications 
for the basic filtering of alarms which arc commercially 
available include: (1) HP OpenView, 3000 Hanover Street, 
Pallo, Calif. 94304; (2) LattisNet, SynOptics 
Communications, 4401 Great American Pkwy., Santa Clara, 
Calif. 95054; (3) IBM Netview/6000, IBM Corp., Old 
Orchard Road, Armonk, N.Y 10504; and (4) SunNet 
Manager, SunConnect, 2550 Garcia Ave, Mountain View, 
Calif. 94043. 

Unfortunately, in the prior art systems alarms can only be 
received from one network management server. Also there is 
no provision for applying the same policy-based filter to 
multiple network management applications. 

Thus, it is an object of the present invention to provide 
greater control over which alarms get reported to network 
management applications and to provide a means to ensure 
consistency of reported alarms across multiple network 
management applications. 

SUMMARY OF THE INVENTION 
The present invention is directed to an apparatus and 
method of alarm notification which includes: (a) receiving 
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alarms from multiple network management servers; (b) 
assigning policy-based filters to associated network man- 
agement applications; and (c) applying the assigned policy- 
based filters to the alarms and for the alarms that pass the 
filters, generating an alarm notification forwarding the same 5 
to the associated network management applications. 

In an embodiment described herein, a user designates a 
plurality of such filters, which constitute an alarm notifica- 
tion policy, to one or more associated network management 
applications. The policy-based fillers are stored in a JQ 
database, and a tag is assigned for identifying each filter. The 
same filters may be assigned to multiple applications. 

In a further embodiment, the user may schedule the 
assignment of such policy-based filters to occur at a desig- 
nated time in the future. For example, a user may pick a 
policy from a list of available policies to associate with a 15 
selected application, and then designate the frequency with 
which the policy is applied, e.g., once, hourly, daily, weekly 
or monthly. 

Furthermore, the invention can be used in the same mode 
as similar tools in the prior art, i.e., with one alarm- 20 
forwarding component for each network management 
system/network management application pair, or alterna- 
tively as a single entity in a distributed network management 
environment. 

These and other features of the present invention will be 25 
more fully described in the following detailed description 
and figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is an example of an alarm log display provided by 30 
the prior art Spectrum™ network management system. 

FIG. 2 is a block diagram of an alarm notification man- 
ager in accordance with the present invention, in use with 
multiple network management servers and multiple network 
management applications. 35 

FIG. 3 is a flow chart illustrating the application of 
policy-based filters to an alarm, and forwarding of the alarm 
which passes the filters to an application in accordance with 
this invention. 

FIG. 4 is an example of an Associations window display 40 
of the alarm notification manager. 

FIG. 5 is an example of a New Association window 
display of the alarm notification manager. 

FIG. 6 is an example of a Modified Association window 
display for the alarm notification manager. 

FIG. 7 is an example of a Scheduler window display for 
the alarm notification manager. 

FIG. 8 is an example of a Policies window display for the 
alarm notification manager. 5Q 

FIG. 9 is an example of an Open Policy window display 
for the alarm notification manager. 

FIG. 10 is an example of an Add Filter Values window 
display for the alarm notification manager. 

FIG. 11 is an example of an Alarm Age window display 55 
for the alarm notification manager. 

FIG. 12 is an example of a New Policy window display 
for the alarm notification manager. 

FIG. 13 is a block diagram illustrating two separate 
processes between the network management application and 60 
the alarm notification manager. 

FIG. 14 is a block diagram illustrating a central process- 
ing unit and memory for use in this invention. 

DETAILED DESCRIPTION 65 
The present invention is directed to an alarm notification 
manager which receives alarms from multiple network man- 
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agement servers, allows an unlimited number of filters to be 
defined within one policy, allows policies to be named and 
stored in a database, allows policies to be scheduled for 
different times, and allows the same policy to be applied to 
one or more network management applications. 

As illustrated in FIG. 2, a live network 10 is connected by 
links 11 to one or more network management servers 12 
which monitor the network. The servers detect errors or 
faults on the network and send alarm information to the 
alarm notification manager 14 via links 13. The alarm 
notification manager includes a policy database 16, method 
for applying policies to alarms 18, graphical interface 20, 
and scheduler 22. The manager applies policy-based filters 
to the alarm messages received from the servers, and for 
those alarms which pass the filter criteria, an alarm message 
is sent to the appropriate network management application 
24 via links 23. 

In a specific embodiment described herein, a plurality of 
distributed SpectroServers™,part of the Spectrum™ system 
sold by Cabletron Systems, Inc., Rochester, N.H., are used 
to model the live network 10, and several Spectrum™ 
applications receive the filtered alarm messages from the 
manager 14. These components have been implemented in 
the object-oriented programming language C++. However, 
the invention is not tied to any particular language nor to any 
particular products used in network management. 
The Spectrum™ Network Management System 

An understanding of the present invention is furthered by 
an understanding of the model-based network management 
system known as Spectrum™, which is described in U.S. 
Pat. No. 5,261,044, issued Nov. 9, 1993 to R. Dcv ct aL, and 
hereby incorporated by reference in its entirety. The Spec- 
trum™ network management system is commercially avail- 
able and also described in various user manuals and litera- 
ture available from Cabletron Systems, Inc., Rochester, N.H. 

In summary, Spectrum™ is a system for maintaining and 
processing information pertaining to the condition of the 
computer network and providing the same to a user, the 
network including a plurality of network entities such as 
computer devices and software applications being executed 
on such devices. The system includes a virtual network 
machine, comprising a programmed digital computer, 
wherein a program is implemented using an object-oriented 
programming language such as C++, Eiffel, SmallTalk, and 
Ada. The virtual network consists of interrelated intelligent 
models of network entities and relations between network 
entities, including means for acquiring network data per- 
taining to the condition of a network entity from the corre- 
sponding network entity. The virtual network further 
includes means for maintaining objects which include net- 
work data relating to the corresponding network entity and 
one or more inference handlers for processing the network 
data, the inference handlers being responsive to changes 
occurring in the same and/or a different object. The network 
data can then be transferred to a user interface coupled to the 
virtual network machine, for supplying the network data to 
a user. 

Thus, the models are implemented as software "objects** 
containing both "data" (attributes) relating to the corre- 
sponding network entity and one or more "inference han- 
dlers" (functions) for processing the data. See Grady Booch, 
"Object-Oriented Analysis And Design, With Applications," 
2nd Edition, Benjamin/Cummings Publishing Co., Red- 
wood City, Calif., Chapter 2, 1994. The inference handlers 
are initialed by predetermined virtual network events, such 
as a change in specified network data in the same model, a 
change in specified network data in a different model, and 
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predefined events or changes in models or model relations. Association 

Information pertaining to the condition of the network entity When the user associates a policy with an application, he 

can be obtained from the network entity by polling the same, is specifying the filter criteria that SANM should apply 

can be automatically received from the network entity to the alarms it sends to the application, 
(without polling), or can be inferred from data contained in 5 A filter consists of a list of filter parameters and a list of 

other models. An alarm condition may be generated when associated filter values. A user (of a network management 

the network data meets a predetermined criteria. Events, application) specifies the value(s) that each filter parameter 

alarms and statistical information from the virtual network caD take «» order for a given alarm to pass the filter criteria, 

are stored in a database and are selectively displayed for the The followin g is a list of representative filter parameters: 
user. io mode! name 

The data in the Spectrum™ database may be used for model type name 

generating topological displays of the network, showing device IP subnet 

hierarchial relationships between network devices, isolating device location 

a network fault, and reviewing statistical information. alarm severity 

Spectrum™ allows for collective management of autono- 15 a ] arm agc 

mous local area networks (LANs), with equipment from SpectroSERVER host name 

different vendors. It complies with the current Simple Net- landscaoe name 

work Management Protocol (SNMP) standards, and can also , ^ 

accommodate other standard and proprietary protocols. The alarm cause ...... 

virtual network machine preprocesses the raw information 20 ^ ™ UC fo ' cach of l T h M c abovc ^ ter P a «meters would be 

coming from the network devices in order to construct a rCCC1 !^ fr ° m S P cclrum ™. ^P 1 f ° r fj« alarm age param- 

model of the network's current status and performance CtC J' ^ R ala ™ a f Parameter is used internally by SANM 

characteristics. Network elements that cannot be directly SpCClfi ? S tbe length of 1 time tba ! e a * hoM hold an aIarm 

communicated with (e.g., cables and buildings) can infer ^fore xn * m f> U to an a PP ilcatlon - » ^ " cleared by 

their status from the status of the devices connected to (or 25 5?™ dUnn * ^ T' T D ° l ^ l ° !hC a PP licalion - 

contained within) them. The virtual network machine pro- ™Jf m * T '° ^ ° Ut lraDS ! em alarmS * 

vides a consistent interface for management applications to . J?"* fil f * a,u . e a corresponding flag which 

access any of the information in the model and thereby mdlCale ? whether " shouid be ne S ated ' For exam P le > if lhc 

provides these applications with a unified view of the ^ ' * f 0 ' ° F * J 00 * 1 ^ Dame , VaIue f of Hub - 

network 30 CSI — IRM3 » tnis filte r value states that all alarms for models 

Spectrum's™ associated SpectroGRAPH™ user inter- N °T ° f lype " u b_CSI_IRM3 should pass, 

face provides a highly graphical multi-perspective view into ff niplex filtering caii be achieved by defining 

the network model. SpectroGRAPH™ enables the user to muItiple f 1 ™ wlthlD a pohcy ' Each fiUer specifies a sepa- 

navigate through a landscape in which cables, networks, fat * f!L^ f , VaIueS : . , Am g n L £1 

local area networks and even rooms show up as icons, and 35 . S ~^l P erforms a lo S lcal AND of all the filter criteria 

which icons indicate the health and performance character- W1t £ m a filt f r and performs a lo S ical 0R betweeo ail filters 

istics of those elements. These icons can be further queried within a policy. 

for additional information. SpectroGRAPH™'s main func- F ° r exam P le ' a P ollc y contains two filters as follows: 

tion is to visually present to the user the model within the Fll ^ r * 

virtual network machine. It allows the user to navigate freely 40 Model Type: Rtr_Cisco 

within the network model, only limited by the access rights . ^"dscape: wiz 

assigned by the network administrator. The information can filter ^ 

be accessed at varying degrees of detail, from a macro Model T >'P e: Rtr_WeIlfleet 

overview, to the devices and cables which connect them. In Landscape: brat 

addition to its navigation functions, SpectroGRAPH™ pro- 45 SANM would apply this policy to a given alarm as 

vides an alarm management facility, an event log window, a follows: 

reporting facility, a find facility, and other features. IF tQC alarm has: 

The above description of the Spectrum™ system provides model type Rtr_Cisco AND landscape wiz 

a context for an understanding of the present invention. OR 

The Alarm Notification Manager 50 model type Rtr_Wellfleet AND landscape brat 

The following definitions are helpful to an understanding THEN send the alarm to the application. 

of the present invention: Each filler also contains a filter tag, which is a text string 

SANM that the user enters. This tag, which is included in the alarm 

SPECTRUM™ Alarm Notification Manager notification, identifies which filters) passed and can be used 

Policy 55 by an application to perform routing of alarms. 

Aset of criteria which a given alarm must satisfy in order J°\^l7hl^ZT h "T " D !* entered in ' be 

to be passed to the application with which the policy is fiher 'l 8 ° f MCh fl V*" lf ^ Cntena m one fil,er 

associated. A policy may consist of one or more niters. ap ? 1,ca "°" W i? n0Ufy 3 P articular whereas if 

Fiher 'he criteria in another filler pass, the application will notify 

. „, - ... . . . . , 60 a different user. If multiple filters pass, a list of correspond- 

m i. i para ™ etefS a ," d , assoc,ate r d fi , lter : alues - ing filter tags is sent in the alarm notification. 

Multiple filters define multiple sets of values for the Another example of the SANM filtering mechanism is 

Fillet P?rJm5£ Sh ° W ° F ' G - 3 " In lhiS figUfe ' lhe Cfilefia lisled wilhin eacb 

filter are the criteria for which values have been specified by 

A data type such as model name or IP subnet for which the 65 the user. It can be seen from this example that all filters are 

user can specify a value or list of values. SANM applied in parallel to a given alarm (i.e., a logical OR is 

provides the user with a fixed list of filler parameters. performed between filters). However, all criteria within a 
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given filter must be satisfied for the alarm lo pass the filter 
(i.e., a logical AND is performed between the criteria within 
a given filter). Since, in this example, the alarm passes the 
criteria in filters 1 and 3, an alarm notification containing 
fitter tags "A" and "C is sent to the application. 

Policies and the associations between policies and appli- 
cations arc stored in the SPECTRUM™ database. This 
means that the same policies arc available to any client 
machine running SANM. It also means that the policy names 
contained in event messages logged by SANM have signifi- 
cance to all client machines using the same SPECTRUM™ 
database. 

1.0 Alarm Notification 

After an application has registered with SANM to receive 
alarms, an alarm notification is sent to that application each 
time an alarm is received from SPECTRUM™ that passes 
the criteria specified in the policy associated with that 
application. The information contained in each alarm noti- 
fication consists of the real-lime values of each filter 
parameters, plus the values of the following parameters: 

model handle 

model type handle 

model condition value 

model security string 

alarm ID 

alarm time j 
alarm probable cause 
alarm status 

event message associated with alarm 
assigned repair person 
user-clearable flag 

One exception to this is that an IP subnet address may be 
specified as a filter criterion, but the full IP address of the 
device that created the alarm is passed in the alarm notifi- 
cation. 

A notification that an alarm has been cleared or updated 
is sent to an application when SANM receives such a 
notification from SPECTRUM™, but only if the alarm 
which is being cleared or updated was initially sent to the 
application when it occurred (i.e., it passed the filter criteria 
for that application). 

2.0 Configuration Tool 
The SANM Configuration Tool enables the user lo define 

Alarm Notification Policies and to associate these policies 
with the applications that use SANM. 

The Configuration Tool is invoked by selecting Alarm 
Notification Manager from the asterisk menu of Spec- 
troGRAPH™. 

2.1 Associations Window 
When the Configuration Tool is invoked, the first window 

to appear is the Associations window, shown in FIG. 4. This 
window displays a list of the currently defined SANM 
applications and the policy that is associated with each of 
them. 

A new association is created by selecting New from the 
File menu. This brings up the New Association window 
shown in FIG. 5. 

An existing association is modified by selecting the 
association and then selecting Modify from the File menu. 
This brings up the Modify Association window shown in 
FIG. 6. 

An existing association is deleted by selecting the asso- 
ciation and then selecting Delete from the File menu. The 
selected association is deleted after the user confirms the 
operation in a Confirmation Dialog window (not shown). 
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The modification of an existing association can be sched- 
uled by selecting the association and then selecting Schedule 
from the File menu. This brings up the Scheduler window 
shown in FIG. 7. 
5 All currently defined policies can be viewed by selecting 
Policies from the Tools menu. This brings up the Policies 
window shown in FIG. 8. 

2.2 New Association Window 

The New Association Window is illustrated in FIG. 5. In 
to this window, a policy is selected from the List of available 
policies and the application name is entered. When OK is 
pressed, the window disappears and the new association 
appears in the Associations window (FIG. 4). 

2.3 Modify Association Window 

is The Modify Association window is illustrated in FIG. 6. 
In this window, the user picks a policy from the list of 
available policies to associate with the selected application 
(SpectroPHONE™ in this example, available from 
Cabletron Systems, Inc.). Pressing OK makes this window 

20 disappear and the modified association is displayed in the 
Associations window (FIG. 4). 

2.4 Scheduler Window 

The Scheduler window is illustrated in FIG. 7. Pressing 
the Associate button brings up the Modify Association 

25 window illustrated in FIG. 6. In the Modify Association 
window, the user picks a policy from the list of available 
policies to associate with the selected application 
(SpectroPHONE™ in this example). In the Scheduler 
window, the user then presses the Frequency button to 

30 specify the frequency of the association. The Frequency 
options are: Once, Hourly, Daily, Weekly and Monthly. The 
information in the area below the Frequency button changes 
depending on what frequency option is selected as follows: 
The Once option allows the user to specify the month, day 

35 and start-time. 

The Hourly option allows the user to specify the number 

of minutes after each hour. 
The Daily option allows the user to specify the time. 
40 The Weekly option allows the user to specify the day of 
the week and the time. 
The Monthly option allows the user to specify the day of 

the month and the time. 
Once the desired scheduling options have been selected, 
45 pressing the Add button inserts the scheduling information 
into the Scheduled Entries portion of the window. Further 
entries can be added by repeating the previous steps. Entries 
can be modified and removed by selecting them and using 
the Modify and Remove buttons. 
50 2.5 Policies Window 

The Policies Window is illustrated in FIG. 8. This window 
shows all currently defined policies. 

A new policy is created by selecting New from the File 
menu. This causes the New Policy window (FIG. 12) to 
55 appear. 

An existing policy is viewed and modified by selecting 
the policy and then selecting Open from the File menu. This 
causes the open Policy window (FIG. 9) to appear. 
An existing policy is deleted by selecting the policy and 
60 then selecting Delete from the File menu. The selected 
policy is deleted after the user confirms the operation in a 
Confirmation Dialog window (not shown). 
2.6 Open Policy Window 
The Open Policy window is illustrated in FIG. 9. This 
65 window shows all the filters that make up the policy. In the 
example shown in FIG. 9, Filters 1 and 2 are visible,, but 
subsequent filters can be viewed using the scrollbar on the 
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right of the window. Similarly, the other filter parameters for 
Filter 1 and their associated values can be viewed using the 
scrollbar below the Filter 1 filter parameters. 

To modify the displayed policy, Edit must be selected 
from the File menu. The View item in the menu bar then 5 
becomes Edit. Once in Edit mode, multiple values for a 
particular filter parameter can be deleted or negated by 
selecting the values and pressing the Delete or Negate 
button. Values can be added for a particular filter parameter 
by pressing the filter parameter button (e.g. Landscape or 10 
Model Type). This brings up a separate window containing 
a list of available values from which multiple values can be 
selected. An example of this window is shown in FIG. 10. 

Filter parameters may be added to a filter by pressing the 
Parameter button within the filter. A pop-up menu appears 15 
containing all eight filter parameters. However, those filter 
parameters which are already present in the filter are greyed- 
out and cannot be selected. Selecting one of the available 
filter parameters from this menu causes the new filter 
parameter and associated value box to appear in the filter. 20 

The alarm age for a particular filter can be modified by 
pressing the Age button in the Open Policy window. This 
brings up the Alarm Age window shown in FIG. 11. The 
values for the Hours and Minutes fields initially contain the 
values from the Age text field in the Open Policy window. 25 
These values can be modified using the up and down arrow 
buttons for hours and minutes. 

A filter tag can be modified in the Open Policy window by 
typing directly into the Tag text field of a filter. 

A new filler may be added to the policy displayed in the 30 
Open Policy window by pressing the Create Filter button. 
This will cause a new filter with no filter parameters to be 
added to the end of the list of filters. 

An existing filter may also be duplicated. To do this the 
filler to be duplicated must first be selected by clicking 35 
within the filter label field (e.g. the area around the label 
Filter 2) and then pressing the Duplicate Filter button. Doing 
this causes a new filter, containing the same filter parameters 
and values as the selected filter, to be added to the end of the 
filter list. This new filter can then be modified. 40 

After modifying a policy, Save can be selected from the 
File menu to save the modified policy under its existing 
name, or Save As can be selected to save the modified policy 
under a di fife rent name. 

The information in the Open Policy window can be 45 
printed by selecting Print from the File menu. 
2.7 New Policy Window 

The New Policy Window is illustrated in FIG. 12. The 
operations that can be performed in the New Policy window 
are the same as those performed in the Open Policy window 50 
(FIG. 9). No filter parameters initially appear within Filter 1, 
therefore the first operation that needs to be performed is to 
select a filter parameter by pressing the Parameter button 
within Filter 1. All filter parameters arc available from the 
pop-up menu at this point because the filter does not yet 55 
contain any filter parameters. 

A new policy is saved by selecting Save As from the File 
menu and entering the name for the policy in a dialog box, 
3.0 Integration of SANM and Application 

A developer would use the following interface to integrate 60 
an application written in C or C++ with the Spectrum™ 
alarm mechanism. 

An application using SANM to receive alarm notifications 
and to clear/acknowledge alarms requires two separate 
processes, as illustrated in FIG. 13. 65 

As an example of how these two separate processes would 
be used in an application, the ARS Gateway™ product 
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would use Process 1 to receive filtered alarms from SANM, 
format them into Trouble Tickets and put them into the ARS 
Database. Process 2 would be used when a user viewing a 
particular Trouble Ticket pressed a clear or acknowledge 
button in the Trouble Ticket. 

Two different programming paradigms are required for 
the two application processes that use SANM: 

For the process that receives alarm notifications from 
SANM, an asynchronous callback paradigm is used. This 
means that when the application code registers with SANM 
to receive alarms, it hands program control over to SANM. 
When SANM needs to send an alarm notification to the 
application, the application receives a callback from SANM. 
This process is terminated by sending it a TERM (terminate, 
15) signal. 

For the process that clears or acknowledges alarms, 
however, a synchronous paradigm is used. This means that 
the application code in this process has program control. 
When this application code makes a call to the SANM API 
to clear or acknowledge an alarm, the call blocks the 
application until it is finished. 
3.1 Definitions and Data Structures 

All definitions and data structures are contained in the 
SANM header file sanm.h and are described below. 

The prototype for the application's callback functions is 
defined as follows: typedef void (*SANMCb) (struct 
SANM__Alarm_Notify *); 

All the data in an alarm notification is contained in the 
SANM_Alarm_Notify structure, which is defined as fol- 
lows: 



struct SANM_Alarm_Notify{ 



char 


•model_name; 


SANMUlong 


model_handle; 


char 


•modcl_typc_namc; 


SANMUlong 


mode l_type_handl c; 


int 


condition_va luc; 


char 


*security_string; 


SANMUlong 


alnnn_rD; 


SAN MTimcs Lamp 


alarm_time; 


SANMUlong 


cau6*_code; 


char 


•probablc_cause; 


char 


*alarm_etMU£; 


char 


•event_messagc; 


char 


•repair_person; 


char 


•lP_addrcas; 


char 


"location; 


SANMUlong 


severity; 


SANMUlong 


alarm _age; 


char 


•SpectroSERVER_host; 


char 


'landscape; 


SANMBoolean 


user_clearable; 


char 


•filtcr_lag; 



}; 



All errors and warnings are defined in the enumeration 
SANM error as follows: 

enum SANM_error 

{ 

SANM_RETURN_OK, 
SANM_INVALID_ALARM, 
SANM_INVALID_LANDSCAPE, 
SANM_ALARM_NOT_CLEARABLE, 
SANM_REGISTER_ERROR } 
3.2 Functions 

The functions that make up the SANM C/C++ API are 
described in the following sections in manual page format. 
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3.2.1 SANMInit 3.2.3 SANMClear 

NAME NAME 

SANMInit-initialize interaction with SANM SANMClear-^clear an alarm 

SYNOPSIS SYNOPSIS 

* i a « u« 5 include "sanm.h" 

^include saom.fa ' SANM_crror SANMClear (SANMUIong alarm_ID, 

SANM_crror SANMInit (char *application_name t char "landscape); 

SANMBooIean rcv_or_clr); DESCRIPTION 

DESCRIPTION SANMClear clears an alarm in SPECTRUM. An appli- 

SANMInit serves to initialize the program for interaction 10 cati ° n can °" 1 >' clcar alarms for which il received 

with SANM. This function should be called from notifications from ^ M ^- "« r ^-clcarablc 

u«iu i- *• L e iL " a 8 must have been set to CLEARABLE in the alarm 

within both application processes before any other notification 

function in the SANM API. INPUT ARGUMENTS 

INPUT ARGUMENTS }$ alarm ., D 

applicatioo_name the ID of the alarm to be cleared 

the name which must be used by the user to identify this landscape 

application when using the Configuration Tool to the landscape that generated the alarm 

associate a policy with it. RETURN VALUES 

rev_or_cir 20 status 

a flag which indicates whether this process is going to retum value will be one of the following values: 

receive alarm notifications or clear/acknowledge SANM_RETURN_OK 

alarms. The flag can take either of the following two SANM_INVALID_ALARM 

values . B SANM_INVALID_LANDSCAPE 

SANM_RCV_ ALARMS * „ A SANM ALARM_NOT_CLEARABLE 

SANM_CLR_ALARMS tr A xV^ 

RETURN VALUES NAME 

SANMAck — acknowledge an alarm 

status SYNOPSIS 

The return value will be one of the following values: «. , . M ,„ 

CAMXJ f ncnrnvr ™ mnclude "sanm.h 

SANM_RETURN OK 30 CAmi oaktha i , rT ^ 

c a xi»/n • SANM_error SANMAck (SANMUIong a!arm_ID, 

3.2.2 SANMRegister char landscape); 

NAME DESCRIPTION 

SANMRegister— register with SANM SANMAck acknowledges an alarm in SPECTRUM. An 

SYNOPSIS 35 application can only acknowledge alarms for which it 

#include "sanm.h" received notifications from SANM. 

S ANM_error SANMRegister (SANMCb set_cb, INPUT ARGUMENTS 

SANMCb clear_cb, alarm_ID 

SANMCb update_cb ); the ID of the alarm to be acknowledged 

DESCRIPTION 40 landscape 

SANMRegister registers the application to receive alarm lhe landscape that generated the alarm 

notifications from SANM. By calling this function, the RETURN VALUES 

application hands program control over to SANM until status 

one of the application's callback functions is called. The return value will be one of the following values: 

INPUT ARGUMENTS 45 SANM_RETURN_OK 

sct_cb SANM INVALI D_ALARM 

the name of the function that SANM will call in order SANM INVALI D_LANDSCAPE 

to send an alarm notification for a new alarm. All Thc P resenl embodiments may be implemented in a 

applications must pass a valid function for this S ene ral purpose computer 70 as shown in FIG, 14. The 

parameter. 50 g c "cral purpose computer may include a computer process- 

clear_cb ing unit ( cpu )- 71 > memory 72, a processing bus 73 by 

the name of the function that SANM will call in order " hich ? U " n aCCC * s thc mcmo ^ and inlcrfacc 74 10 

to send an alarm notification for a cleared alarm. This ^^^^^^^l m ^ 

parameter can be NULL if the application does not „ nil "l^T C f h ™' ^ 'nvcntion ™ v a con> 

want to receive notifications for cleared alarms. 55 pUler 3pP ~ Whlch P^™™** of any of the 

. , previous embodiments. Alternatively, the invention may be 

up ate_c a memory, such as a floppy disk, compact disk, or hard drive, 

the name of the function that SANM will call m order lnat contains lhe £ r program H or dala slniclure) for 

to send an alarm no^calion for an updated alarm. providing to a general purpose computer instructions and 

This parameter can be NULL if the apphcatton does 60 dala for carrying om lhe functions of lhe ious embodi . 

not want to receive notifications for updated alarms. ment. 

RETURN VALUES Having thus described certain particular embodiments of 

slatus lhe invention, various modifications will readily occur to 

In normal operation, this function will never return. those skilled in the art which are intended to be within the 

However, if it fails, one of the following errors will 65 scope of this invention. Accordingly, the foregoing descrip- 

be returned: lion is by way of example only, and not intended to be 

SANM_REGISTER_ERROR limiting. 
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What is claimed is: 

1. A method of alarm notification comprising the steps of: 

(a) receiving alarms from multiple network management 
servers; 5 

(b) creating, in response to a user action, a plurality of 
policy-based filters; and 

(c) applying the policy-based filters to the received 
alarms, generating an alarm notification and forwarding 
the same to at least one network management applica- 10 
tion. 

2. The method of claim I, wherein: 

the creating step includes creating a plurality of filters 
comprising a policy. 

3. The method of claim 2, wherein: 

each filter comprises at least one filter parameter; and 
the applying step comprises performing a logical AND of 
all parameters within one filter and performing a logical 
OR between all filters within one policy. 20 

4. The method of claim 3, wherein: 

the generating step includes specifying real-time values of 
each filter parameter in the alarm notification. 

5. The method of claim 2, wherein: 

the creating step includes storing a policy name and at 25 
least one associated network management application 
in a database accessible to all servers. 

6. The method of claim 1, wherein: 

the creating step includes assigning a tag to each filter. 30 

7. The method of claim 6, wherein: 

the generating step includes specifying the tag for the 
filter which the alarm passed in the alarm notification. 



14 

8. The method of claim 2, wherein: 

the creating step includes storing the filters in a database. 

9. The method of claim 2, wherein: 

the generating step further includes specifying a user 
name in the alarm notification to enable an application 
which receives the alarm notification to notify a user 
having the specified user name. 

10. The method of claim 2, wherein: 

the creating step includes scheduling the creating to occur 
at a specified time. 

11. The method of claim 2, further comprising: 

(d) following resolution of an alarm, forwarding an alarm 
clear message to the at least one network management 
application, 

12. The method of claim 2, wherein: 

the creating step includes assigning the same filters to 
multiple network management applications. 

13. The method of claim 2, wherein: 

the creating step is performed by a user via a graphical 
user interface. 

14. The method of claim 2, wherein: 

the generating step includes generating an alarm notifi- 
cation which contains information about the device 
which generated the alarm. 

15. The method of claim 2, further comprising: 

the at least one network management application gener- 
ating an alarm clear message and forwarding the same 
to the network management server which generated the 
alarm. 

* * • * * 
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SYSTEM AND METHOD FOR A MULTI- or with the same layer of a network element within the 

LAYER NETWORK ELEMENT network itself. A layer implements a set of functions that are 

usually logically related and enable the operation of the 

FIELD OF THE INVENTION layer above it. 

T^e present invention relates in general to packet for- 5 ™ e relevant layers for describing this invention include 

warding within a network and, in particular, to a system and ? SI 1 trough 4. Layer 1, the physical layer, provides 

method for forwarding packets using multi-layer informa- ^^Jv "P^ind itoeiw unsinictu^ bit patterns over 

^ on & r 6 7 a physical link. The physical layer concerns itself with such 

issues as the size and shape of connectors, conversion of bits 
BACKGROUND OF THE INVENTION 10 10 cIcclrical signals, and bil-Ievel synchronization. More 

than one type of physical layer may exist within a network. 

Communication between computers has become an Two common types of Layer 1 are found within IEEE 
important aspect of everyday life in both private and busi- Standard 802.3 and FDDI (Fiber Distributed Data Interface), 
ness environments. Networks provide a medium for this Layer 2, the data link layer, provides support for framing, 
communication and further for communication between error detecting, accessing the transport media, and address- 
various types of elements connected to the network such as 1 ing between end stations interconnected at or below layer 2. 
servers, personal computers, workstations, memory storage The data link layer is typically designed to carry packets of 
systems, or any other component capable of receiving or information across a single hop, i.e., from one end station to 
transmitting data to or from the network. The elements another within the same subnet, or LAN. 
communicate with each other using defined protocols that Layer 3, the network layer, provides support for such 
define the orderly transmission and receipt of information. functions as end to end addressing, network topological 
In general, the elements view the network as a cloud to information, routing, and packet fragmentation. This layer 
which they are attached and for the most part do not need to may be configured to send packets along the best "route" 
know the details of the network architecture such as how the from its source to its final destination. An additional feature 
network operates or how it is implemented. Ideally, any of this layer is the capability to relay information about 
network architecture should support a wide range of appli- 25 network congestion to the source or destination if conditions 
cations and allow a wide range of underlying technologies. warrant. 

The network architecture should also work weU for/very Uyer 4, the transport layer, provides application pro- 
large networks, be efficient for small networks, and adapt to grams such as an electronic mail program with a "port 
changing network conditions. ^ address" which the application can use to interface with the 

Networks can be generally be differentiated based on their data link layer. A key difference between the transport layer 

size. At the lower end, a local area network (LAN) describes and the lower layers is that an application on a source end 

a network having characteristics including multiple systems station can carry out a conversation with a similar applica- 

attached to a shared medium, high total bandwidth, low tion on a destination end station anywhere in the network; 

delay, low error rates, broadcast capability, limited 35 whereas the lower layers carry on conversations with end 

geography, and a limited number of stations, and are gen- stations which are its immediate neighbors in the network, 

erally not subject to post, telegraph, and telephone regula- Layer 4 protocols also support reliable connection oriented 

uon. At the upper end, an enterprise network describes services, an example Layer 4 protocol providing such ser- 

connections of wide area networks and LANs connecting vices is the Transport Control Protocol (TCP), 

diverse business units within a geographically diverse busi- 4Q Different building blocks exist for implementing net- 

ness organization, wotVs that operate at these layers. End stations are the end 

To facilitate communication within larger networks, the points of a network and can function as sources, destinations 

networks are typically partitioned into subnetworks, each and network elements or any other intermediate point for 

sharing some common characteristic such as geographical forwarding data received from a source to a destination, 

location or functional purpose, for example. The partitioning 45 At the simplest level are repeaters which are physical 

serves two main purposes: to break the whole network down layer relays which simply forward bits at Layer 1. 

into manageable parts and to logically (or physically) group Bridges represent the next level above repeaters and are 

users of the network. Network addressing schemes may take dala link layer entities which forward packets within a single 

such partitioning into account and thus an address may lan ^ % look . up tables> ncy do DQt modif packetS( bu , 

contain information about how the network is partitioned 50 just forward packets based on a destination. Most bridges are 

and where the address fits into the network hierarchy. teaming bridges. In these bridges, if the bridge has previ- 

For descriptive and implemenlive purposes, a network ously learned a source, it already knows to which port to 

may be described as having multiple layers with end devices forward the packet. If the bridge has not yet forwarded a 

attached to it, communicating with each other using peer- packet from the destination, the bridge does not know the 

to-peer protocols. The well-known Open Systems Intercon- 55 port location of the destination, and forwards the packet to 

nection (OSI) Reference Model provides a generalized way all unblocked output ports, excluding the port of arrival, 

to view a network using seven layers and is a convenient Other than acquiring a knowledge of which ports sources are 

reference for mapping the functionality of other models and transmitting packets to, the bridge has no knowledge of the 

actual implementations. The distinctions between the layers network topology. Many LANs can be implemented using 

in any given model is clear, but the implementation of any 50 bridges only. 

given model or mapping of layers between different models Routers are network layer entities which can forward 

is not. For example, the standard promulgated by the Insti- packets between LANs. They have the potential to use the 

tute of Electrical and eectronics Engineers (IEEE) in its 802 best path that exists between sources and destinations based 

protocols defines standards for LANs and its definitions on information exchanged with other routers that allow the 

overlap the bottom two layers of the OSI model. 65 rout ers to have knowledge of the topology of the network. 

In any such model, a given layer communicates either Factors contributing to the "best" path might include cost, 

with the same layer of a peer end station across the network, speed, traffic, and bandwidth, as well as others. 
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Brouters are routers which can also perform as bridges. The current Internet is being forced to deal with increas- 
For those layer 3 protocols of which the brouter knows, it ing numbers of users and increasing demands of multimedia 

uses its software to determine how to forward the packet. applications. Future networks will be required to support 

For all other packets, the brouter acts as a bridge. ev en higher bandwidth, larger numbers of users, and traffic 

Switches are generalized network elements for forward- 5 classification requirements by the network. Statistical stud- 

ing packets wherein the composition of the switch and ICS show ^ the DCtwork domain as wdl as thc Dumbcr of 

whether it implements layer 2 or layer 3 is not relevant. workstations connected to the network will grow at a faster 

f j / « * ratc lD future. The trend is also to support multiple traffic 

Typically, bridges forward packets in a flat network typcs with varicd cnaractcristics 0D a um physical link, 

without any cooperation by the end stations, because the This calls for more network bandwidth and efficient usage of 

LAN contains no topological hierarchy. If a LAN, for 10 resources. To meet the bandwidth requirement, the speed on 

example, is designed to support layer 3 functionality, then (he networks is on the upward trend, reaching to gigabit 

routers are used to interconnect and forward packets within speeds. 

the LAN. Network designers frequently use one particular corabi- 
Bridges cannot use hierarchical routing addresses because nation of ISO Layer 2 and Layer 3 because of the success of 
they base their forward ing decisions on media access control 15 the Internet and thc increasing number of products and 
(MAC) addresses which contain no topological significance. networks using the Internet. Specifically, in a typical 
Typically MAC addresses are assigned to a device at its time Internet-associated network, designers combine an imple- 
of manufacture. The number of stations that can be inter- mentation in accordance with thc IEEE 802 Standard (which 
connected through bridges is limited because traffic overlaps ISO Layer 1 and Layer 2) with the Internet Protocol 
isolation, bandwidth, fault detecting, and management (IP) network layer. This combination is also becoming 
aspects become too difficult or burdensome as the number of popular within enterprise networks such as intranets, 
end stations increases. Supporting this combination by building networks out of 
Learning bridges self-configure, allowing them to be layer 2 network elements provides fast packet forwarding 
"plug and play" entities requiring virtually no human inter- 25 but has little flexibility in terms of traffic isolation, redundant 
action for setup. Routers, however, require intensive topologies, and end-to-end policies for queuing and admin- 
configuration, and may even require configuration activities istration (access control). Building such networks out of 
at tbe end nodes. For example, when a network utilizes the layer 3 elements alone sacrifices performance and is imprac- 
Transmission Control Protocol/Internet Protocol (TCP/IP), lical from the hierarchical point of view because of the 
each end node must manually receive its address and subnet 3Q overhead associated with having to parse the layer 3 header 
mask from an operator, and such information must be input and modify the packet if necessary. Furthermore, using 
to the router. solely layer 3 elements forces an addressing model with one 
Generally, as the size and complexity of a network end station per subnet, and no layer 2 connectivity between 
increases, the network requires more functionality at the the end stations. 

higher layers. For example, a relatively small LAN can be 35 Networks built out of a combination of layer 2 and layer 

implemented by using Layer 1 elements such as repeaters or 3 devices are used today, but suffer from performance and 

bridges, while a very large network uses up to and including flexibility shortcomings. Specifically, with increasing varia- 

Layer 3 elements such as routers. lion in traffic distribution (the rote of the "server" has 

A single LAN is typically insufficient to meet the require- multiplied with browser-based applications), the need to 
ments of an organization because of the inherent limitations: 40 traverse routers at high speed is crucial. 
(1) on the number of end stations that can be attached to a The choice between bridges and routers typically results 
physical layer segment; (2) the physical layer segment size; in significant tradeoffs (in functionality when using bridges, 
and (3) the amount of traffic, which is limited because the and in speed when using routers). Furthermore, the service 
bandwidth of the segment must be shared among all the characteristics, such as priority, within a network are gen- 
connected end stations. In order to overcome these 4S erally no longer homogeneous, despite whether traffic pat- 
constraints, other network building blocks arc required. terns involve routers. In these networks, differing traffic 

As briefly described above, when the number of end types exists and require different service characteristics such 

stations in a network increases, the network may be parti- as bandwidth, delay, and etc. 

tioned into subnetworks. A typical address in a partitioned To meet the traffic requirements of applications, the 

network includes two parts: a first part indicating the sub- 50 bridging devices should operate at line speeds, i.e., they 

network; and a second part indicating an address within the operate at or faster than the speed at which packets arrive at 

subnetwork. These types of addresses convey topological the device, but they also must be able to forward packets 

information because the first part of the address defines across domains/subnetworks. Even through current hybrid 

geographical or logical portions of the network and the bridge/router designs are able to achieve correct network 

second part defines an end station within the subnetwork 55 delivery functions, they are not able to meet today's increas- 

portion. Routing with hierarchial addressing involves two ing speed requirements. 

steps: first packets are routed to thc destination's subnet- What is needed is a switch or network element that 

work; and second packets are forwarded to the destination forwards both layer 2 and layer 3 packets quickly and 

within thc subnetwork. efficiently both within a subnetwork and across 

An end station receives a unique data link address — the 60 subnetworks, and to other networks. Further, a network 

MAC address — at the time of manufacture, allowing the end element is needed that can forward layer 3 packets at 

station to attach to any LAN within a bridged network wire-speed, i.e., as fast as packets enter the network element, 

without worrying about duplicate addresses. Data link Additionally, a network element is needed that allows layer 

addresses therefore cannot convey any topological informa- 2 forwarding within a subnetwork to have the additional 

tion. Bridges, unlike routers, forward packets based on data 65 features available in layer 3 routing and to provide certain 

link addresses and thus cannot interpret hierarchical quality of service for applications within the subnetwork, 

addresses. suc h as priority and bandwidth reservation. 
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SUMMARY OF THE INVENTION Still other embodiments of the present invention will 

The present invention enables the above problems to be become readily apparent to those skilled in the art from the 

substantially overcome by providing a system and method following detailed description, wherein is shown and 

for an multi-layer network element for forwarding received described only the embodiments of the invention by way of 

packets to one or more appropriate output ports. 5 illustration of the best modes contemplated for carrying out 

An embodiment of the present invention includes a the invention. As will be realized, the invention is capable of 

method of forwarding an packet entering from an input port ' other and different embodiments and several of its details arc 

to one or more appropriate output ports based on single capable of modification in various obvious respects, all 

searches of an associative memory for each layer. The w *hout departing the spirit and scope of the present inven- 
associative memory contains certain quality of service infor- 10 tl0n * ^o^mgly, the drawings and detailed description are 

mation that may be applied to any layer. t0 as illustrative in nature and not as restrictive. 

A packet is received on an input port, and from the packet BRIEF DESCRIPTION OF THE DRAWINGS 

a first search key is created based on the header of the ™„ , .„ 

packet. An associative memory lookup is performed for the FIG ' 1 j lllustrales a j^tem mcorporatrng a multi-layer 

first search key, which results in two potential forwarding 15 nelWOrk elemenl accordm S 10 the u,ventl0n - 

decisions for the packet. If the first search key matches an FIG - 2 lllustratc s the multi-layer networking element of 
entry to a destination address found in the first search key, 

i.e., a matching entry is found in the associative memory, FIG. 3 illustrates the switching element of the multi-layer 

then the potential output port or ports arc those associated network element in more detail. 

with the destination address as found in the associative 20 FIG. 4 illustrates the forwarding logic of the switching 

memory. If the destination address does not match any entry element in more detail. 

in the associative memory, then all ports except the incom- FIG. 5 illustrates the class logic of FIG. 4 in more detail 

ing port are candidates for the potential output port or ports. FIG , 6 iIlustrates tfac proccss uscd ^ dctcrm i omg which 

The packet is also categorized by class to aid in creating 25 information dictates a packet's path through the multi-layer 

a second search key. Packets of a particular class share network clement 

^Tn^TlTl^,^ aS ^ hal P°" i ° ns ° 4 f "f r FIG. 7 illustrates the information dependency in de.er- 

Zf^n V S6 T d ^T* A , t minin 8 how 10 forward a P acket out of «be networic element. 

defines certain default forwarding information for packets 

within the class. The default information may include certain 30 DETAILED DESCRIPTION 

quality of service information. FIG. 1 illustrates a system incorporating a multi-layer 

An associative memory lookup is performed using the network element according to the present invention. The 

second search key. Tbe results of this second search, the first system includes the multi-layer network element, various 

search, and the default information are combined to deter- networks, end stations, routers, and bridges. By way of 

mine which of the potential output port or ports as proffered 35 example and as broadly embodied and described herein, a 

by the three searches is the most appropriate for this packet. system 10 incorporating a multi-layer network element 12 

The packet is then forwarded to the appropriate output port according to the present invention includes networks 14 and 

or P° rts - 16, end stations 18, router 24, bridge 26, and local area 

In some instances, the second search key yields no match networks (LAN) 28. 

in the associative memory. In these cases, the default infor- 40 The bridge 26 connects some of the LANs 28 and end 

mation is combined with the results of the first search. stations 18 to the network 14 and to each other. The bridge 

Furthermore, the results of the first search may override any 26 may be a conventional learning bridge. The bridge 26 

of the other forwarding information; and the results of the keeps track of the addresses of the end stations 18 that 

second search may force the results of the first search to be transmit a packet showing up on one of ports 30 to the bridge 

used to forward the packet. 45 26. The end stations 18 may be any device capable of 

In one embodiment, the invention implements forwarding sending or receiving packets of information. Typically, the 
of layer 2 and layer 3 packets. In this embodiment, the first end stations 18 are personal computers, workstations, 
search key includes information about layer 2 destination printers, servers, and/or any other device that can be con- 
addresses and the second search key and default information nected to a network. 

include information about layer 3 and possibly layer 4. 50 The bridge 26 initially does not know on which of its ports 

Such an implementation, in one embodiment, allows packet destinations are located, and must flood an incoming 

certain quality of service to be applied to layer 2 forwarding packet to all ports in order to properly forward the packet, 

in the following manner When a packet enters the network Once the bridge 26 receives a packet destined for an address 

element as a layer 2 packet, the first search key will result it already recognizes, the bridge 26 knows what port the 

in layer 2 forwarding information being output from the 55 destination is on so that it does not have to flood the packet 

associative memory. The class of the packet will be deter- on all outgoing ports. Eventually, the bridge 26 has learned 

mined and the packet provided with default class informa- enough addresses to all but eliminate the amount of flooding 

don that may include certain quality of service information. needed on the ports. Of course, any time an end station 18 

The second search key, however, may not yield any results changes ports on the bridge 26, the bridge 26 must releara 

from the associative memory because an entry in the 60 the end station 18 's port. 

memory has not yet been created by the central processing The bridge 26 typically does not modify the packet, 

unit. In this instance, merge logic will use the layer 2 contains no information about the topology of the network 

forwarding result but also use the quality of service infor- 14, and examines few pans of the packet header. The bridge 

mation from the default forwarding information. Such a 26 operates quickly because it makes no modifications to the 

feature allows the network element to be configured to 65 packet and is only concerned with learning sources and 

provide quality of service to layer 2 traffic within a subnet- forwarding to destinations. Typically, bridges 26 use look-up 

woric - tables to search for sources and destinations. 
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The router 24 connects the network 14 to the networks 16. a router 24. Functioning as a bridge, the multi -layer network 

Only one router 24 is illustrated by way of example, but element 12 learns source/port combinations to forward layer 

there may be many routers connecting other networks or end 2 packets. The multi -layer network element 12 differs from 

stations 18. The router 24 provides the communication conventional bridge/router combinations in that certain layer 

necessary between the network 14 and the networks 16 and 5 3 processing operates as quickly as layer 2 switching found 

may a conventional router. Such routers include layer 3 in the bridge 26. 

functionality for forwarding packets to an appropriate des- FIG. 2 illustrates the multi-layer network element 12 of 

tination including route calculation, packet fragmentation, FIG. 1 in more detail. The multi-layer network element 12 

and congestion control. Routers of this type are described, according to one embodiment of the invention includes a 

for example, in Interconnections: Bridges and Routers by 10 processor 32, a processor memory 34, a switching element 

Radia Perlman published by Addison- Wesley. The router 24 35, a plurality of network element ports 38, a forwarding 

must have knowledge of the topology of the network in memory 40, an associated memory 42, and packet buffer 

order to determine the best route for packets. The router 24 's memory 44. The end stations I 8, the LAN 28, and the 

knowledge of the network is gained through topological network 14 are connected to the multi-layer network ele- 

information passed between multiple such routers 24 con- is ment 12 using a plurality of network element ports 38. Other 

nected to the network 14. multi-layer network elements 12 may also be connected to 

Software running on the router 24 parses an incoming the multi-layer network element 12. 
packet to determine various characteristics about the packet, The switching element 36 is also connected to the pro- 
including the type of the protocol being used and the source C essor 32, the forwarding memory 40, the associated 
and destination(s). Other determinations based on examin- 20 memory 42, and the packet buffer memory 44. The processor 
ing the packet may be necessary, such as priority and quality 32 is also connected to the memory 34. Forwarding memory 
of service (QoS) factors such as priority and bandwidth 40 and associated memory 42 is connected to each other as 
reservation. The router 24 then uses the extracted informa- well to as switching element 36 

tion and computes the next destination for the packet based ^e switching element 36 performs most of the packet 

on topology and route information that is stored in the 25 forwardi fiinctions using both layer 2 and layer 3 

memory of the router 24. The router 24 also applies QoS mformalioDi and po Ssibly ^ ^ layer 4 inform ; iion , 

rules and actions. slorcd in forwarding memory 40 and associated memory 42, 

The router 24 's process for calculating the next destina- without having to rely on the processor 32 to calculate routes 
tion may require many accesses to memory and computation or determine appropriate actions on every packet, 
of the route from that information. Furthermore, the packet 30 -r^ processor 32 performs tasks that the switching eie- 
is typically received and stored while any processing is mcnt 36 & DOl cquippcd t0 handlc> For c lc> ^ Qcw 
taking place. After the router 24 has determined what actions laycr 3 roulcs must ^ calculated, the processor 32 uses 
are necessary on the packet, any modifications are made to processor memory 34, which contains detailed information 
me packet^ stored in the memory or on the way out of the about thc topology of any nctworks rcachablc from tbc 
router 24. The routers24 are typically required to replace the mu lti-laycr network element 12. Thc processor 32 makes its 
layer 2 source and destination of the packet, update any computations primarily using software programming units 
checksums of the packet, and handle any issues related to m conjunction with accesses to the memory 34. Thc switch- 
packet lifetime. c i cment 3 g ma kes its decisions primarily in hardware, 

To carry out the functions that the conventional router 24 4(J using the forwarding memory 40 and the associated memory 

performs, the software examines memory locations, make 42. The forwarding memory 40 and the associated memory 

modifications to the packet, and calculate new values for 42 contain only a portion of the information contained in the 

some fields. Such actions provide increased functionality memory 34, and are configured for quick access and 

beyond simple packet forwarding like that found in bridges retrieval. 

26 such as determining the best route for the packet, 45 FIG. 3 illustrates a detailed view of the switching element 

providing QoS features; however, in conventional routers 24 36 and its connections to the processor 32, the plurality of 

such actions take up valuable time. nctwork clcment ports 38(WIt thc forwarding mcmory 40 , 

The network 14 provides communication paths for all of the associated memory 42, and the packet buffer mcmory 44. 

the elements connected to it. In the example of FIG. 1, the Thc switch clement 36 includes input ports 50a-/i, a for- 

elements include the multi-layer network element 12, router 50 warding logic 52, a packet memory manager 54, and output 

24, and bridge 26. Any number of elements could be ports S6a~n. Each input port 50/ and output port i corre- 

connected to the network 14 in a multitude of ways. FIG. 1 spends to a network element port 38/. Each of the inputs 

illustrates only one possible combination. The elements ports 50 also connects to both the forwarding logic 52 and 

connected to the network 14 do not require the network 14 the packet memory manager 54. 

to be of any particular size or configuration. For the end S5 For a given i, an input port 50/ receives packets from its 
stations 18 and the bridge 26, a detailed topological knowi- respective multi-layer network clement port 38/ and tests thc 
edge of the network 14 is not required. packets for correctness. If the packet is ill formed, it is 
The multi-layer network element 12 according to the discarded. Packets passing this initial screening are tempo- 
present invention connects various elements to the network rarily buffered by the input port 50/. Once the input port 50/ 
14 and to each other. As illustrated by way of example, the 60 has buffered at least the first 64 bytes of the received packet, 
multi-layer network element 12 connects a LAN 28, the end the input port 50/ passes the header to the forwarding logic 
stations 18, and the network 14. The multi-layer network 52. 

element 12 combines the functions of both a bridge and a The forwarding logic 52 is connected to the processor 32, 

router. Functioning as a router, the multi-layer network the forwarding memory 40, and the associated memory 42. 

element 12 contains topological information about network 65 The forwarding logic 52 performs several functions. It 

14 to intelligently route a packet to its destination while initially screens the packet to determine whether the packet 

providing associated layer 3 functionality typically found in is encapsulated, by for example Subnetwork Access Proto- 
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col (SNAP), or whether the packet is tagged, for example, by packets. If this situation is dictated by the results from tbe 

a virtual LAN (VLAN) identifier. If the packet is either of forwarding logic 52 as passed to the input port 50/, the input 

those two types, the forwarding logic 52 uses offset infor- port 50* places such an indication in the packet buffer 

raation to locate appropriate layer header information memory 44, The output port 56/ detects this indication and 

needed for further processing. 5 replaces the address as the packet leaves the output port 56t\ 

The forwarding logic 52 also searches the forwarding Thus, only minor modifications to the packets are necessary 
memory 40 for matches at layer 2 and/or layer 3. The search on the output side of the switching element 36. 
may also include some information at layer 4. In the According to the above embodiment, when the forward- 
preferred embodiment, the forwarding memory 40 is a in g memory 40 contains matching entries for layer 2 switch- 
content-addressable memory (CAM) storing information i° ing or layer 3 routing, the multi-layer network element L2 
about both layer 2 and layer 3 switching, and may contain will operate at wire-speed. Wire-speed is defined by the 
some layer 4 information. If a match is found, data stored in speed at the maximum packet rate at which a given layer 1 
associated memory 42 and pointed to by the matching entry and layer 2 combination can transport packets. If an element 
in the forwarding memory 40 serves to define the actions connected to a network can process packets as fast as they 
that the switching element 36 must do to forward the packet is enter the element or faster, then the element operates at wire 
to the appropriate destinations). speed. 

In another embodiment, the forwarding memory 40 could In a preferred embodiment, the network element 12 

be implemented using an sequentially address random processes packets for a worst-case scenario of a steady 

access memory. In this embodiment, a hashing function stream of 64-byte packets entering all input ports 50 sirnul- 

would be preformed on the particular key. The resulting 20 taneously. If the layer 3 information is not contained in the 

hashed value would be an address into the memory 42 forwarding memory 40, the packet is forwarded using layer 

associated with the pre-hashed key. 2 information and then processed according to conventional 

In still another embodiment, the forwarding memory 40 layer 3 processing by software in the processor 32. 

and the associated memory 42 could be contained in a single Unlike conventional layer 3 processing, the processor 32 

random access memory. In one implementation of that single 25 may update the forwarding memory 40 by placing new layer 

random access memory, the entries could be accessed 3 entries as they are learned and created. Any packets 

sequentially, requiring a hash-front end. Another implemen- matching the new entries are forwarded at wire-speed, i.e. 

tation of that single random access memory could be a forwarding decisions are made for a packet before the next 

CAM. ^ packet arrives. 

The packet memory manager 54 is connected to the While the discussion of this invention is described using 

packet buffer memory 44, the input port 50/, and the output layer 2 and a combination of layers 3 and 4, one skilled in 

port 56/. As indicated above, each output port 56/ corrc- the art would recognize that searching on and creating 

sponds to one of the plurality of multi-layer network clement entries in the forwarding memory 40 for any portion of a 

ports 38/. While illustrated as separate units, the input port 35 packet or its header, or any combination thereof, readily 

50/ and output port 56/ corresponding to a particular multi- flows from the description. Thus, this invention is not 

layer network element port 38/ are tightly coupled since limited to any specific implementation of layers according to 

information flows both ways through the network element the ISO standard. 

P 0Its 35 • FIG. 4 illustrates the forwarding logic 52 in more detail. 

After the forwarding logic 52 has determined what to do 40 The forwarding logic 52 includes class logic 60, layer 2 (L2) 

with tbe packet, it passes that information to the input port logic 62, layer 3 (L3) logic 64, and merge logic 66. The input 

50/. If the input port 50/ does not filter the packet, then it port- 50/ connects to the class logic 60, the L2 logic 62, the 

requests pointer to free memory locations in the packet L3 logic 64, and the merge logic 66. Only one input port 50/ 

buffer memory 44 from the packet memory manager 54. The is shown for simplification, though all input ports 50 arc 

packet memory manager 54 responds by providing location 45 connected in a similar manner. Preferably, the forwarding 

addresses of free memory space in the packet buffer memory logic 52 is not duplicated for each input port 50/. Instead, all 

44. The input port 50/ then requests a write access from the input ports 50 arbitrate for access to the forwarding logic 52. 

packet memory manager 54 and sends the pointer and the The 12 logic 62 is connected to the forwarding memory 

data to the packet memory manager 54. 40 and is responsible for creating a key to match against the 

In some instances, the input port 50/ must make modifi- 50 entries stored in the forwarding memory 40 for layer 2 
cations to the packet as instructed to do so from the forwarding decisions. Depending on the configuration of the 
forwarding logic 52. The input port 50/ makes these modi- forwarding memory 40, the key may be applied against all 
fications prior to the packet being stored in the packet buffer or some of the entries of the forwarding memory 40 
memory 44. When requested by the input port 50/, the During operation, the input port 50/ receives a packet 
packet memory manager 54 places the packet into the 55 from the multi-layer network element port 38/ and sends tbe 
appropriate address location specified by the input port 50/. header plus the input port 50/ identifier to the forwarding 
The input port 50/ then passes information about where the logic 52. The forwarding logic 52 first searches the forward- 
packet is stored to the appropriate output ports 56 as ing memory 40 to determine whether the forwarding 
determined from the information received at the input port memory 40 contains an entry for the layer 2 source trans- 
50/ from the forwarding logic 52. 60 milting the packet. A matching entry will exist if the 

In a preferred embodiment, the appropriate output ports multi-layer network element 12 has previously received a 

may include no output ports or one or more output ports. The packet from the same layer 2 source and has learned which • 

output port 56/ requests and receives packets from the port it is connected to. If no matching entry exists, tbe 

packet manager 54, and transmits the packet to its associated forwarding logic 52 performs a learn function by placing an 

network element port 38/ when the conditions for transmis- 65 entry in the forwarding memory 40 including the source 

sion are met. In some instances, the output port 56/ must address. The forwarding logic 52 signals the processor 32 

place its MAC address as the source address on outgoing that it has learned a new source address. In some instances, 
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the layer 2 source will exist in the forwarding memory 40, determine a class for the layer 3 information and is illus- 

but will be associated with a different input port SOi than the trated in more detail in FIG. 5. The class logic 60 includes 

input port 50i of the incoming packet. In this instance, no the encapsulation logic 68 and the class action logic 70. 

matching entry will exist in the forwarding memory 40 Each input port 50/ is connected to both the encapsulation 

because a match depends on both the layer 2 source and the 5 logic 68 and the class action logic 70. The class action logic 

input port SOi 70 is connected to the encapsulation logic 68, the L3 logic 

The forwarding logic 52 also searches the forwarding 64, and the merge logic 66. 

memory 40 for an entry indicating the port of the destination The encapsulation logic 68 is responsible for examining 

address. If no match is found, then the forwarding logic 52 the packet header and determining any offsets into the 

instructs the input port 50/ to flood the packet to all of the 1Q header for the layer 3 and layer 4 information, if needed. The 

active output ports 56. encapsulation logic 68 includes class filters 72 to determine 

For the layer 2 information described above in the pre- any offsets into the packet to identify locations of relevant 

fcrred embodiment, the forwarding memory 40 contains the information. In a preferred embodiment one filter 72 recog- 

values of the MAC addresses of the sources and a pointer to nizes an implementation in accordance with the IEEE 802.3 

a corresponding entry in the associated memory 42. The Standard Ethernet header, and another filter 72 recognizes an 

forwarding memory 40 may also contain additional layer 2 15 implementation in accordance with the IEEE Standard 

information such as a VLAN identifier if tagged packets arc 802. lq Tagged Ethernet Header, and still another recognizes 

being used. The associated memory 42 contains more infor- an LCC SNAP encapsulation. Other encapsulations would 

raation about its corresponding entry in the forwarding become readily apparent to one skilled in the art and could 

memory 40. Layer 2 information in the forwarding memory be implemented with additional encapsulation fillers 72. The 

40 is preferably limited to the least amount of information 20 encapsulation logic 68 passes encapsulation offsets to the 

necessary to make a layer 2 search. In a layer 2 search, this class action logic 70 so that the class action logic 70 knows 

information is preferably just the MAC address and the input from where in the packet to draw the appropriate field 

port 50i t but the CAM may also contain any information information. 

relating to tagged addressing. ^ The class' action logic 70 determines to which class a 

In a preferred embodiment, the forwarding memory 40 packet belongs. A class is used by both the L2 and L3 logics 

allows multiple matches for a layer 2 search. The processor to aid in searching and to add to the functionality of the 

32 ensures that the order of the entries is such that if an multi-layer network element 12. The L2 logic 62 applies a 

address/port combination exists in the forwarding memory, single class to all layer 2 searches. Layer 3, on the other 

that entry is selected. If the particular source/port combina- 3Q hand, has a plurality of programmable classes, 

tion is not found, then a match may occur including VLAN The classes help to define a class type and for each class 

information, so that any layer 2 destination search will at which bytes from the packet header that should be used in 

least match a known VLAN or an unknown VLAN entry, creating the layer 3 search key by the L3 logic 64, its 

each of which define the output ports 56 for flooding in its priority, and a default class result that defines what should 

respective entry. ^ happen if no layer 3 match occurs in the forwarding memory 

The L3 logic 64 is connected to the forwarding memory 40. 
40 and is responsible for creating a key to match against the In a preferred embodiment, there are four possible out- 
entries stored in the forwarding memory 40 for layer 3 comes when no match occurs. First, the header may be sent 
forwarding decisions. As with the L2 search key, the L3 key to the processor 32. This is contemplated when the possi- 
may be applied against all or some of the entries of the 40 bility of identifying a layer 3 flow exists. Second, the entire 
forwarding memory 40. packet could be copied to the processor 32. This is contem- 

To create the key, the L3 logic 64 uses information from plated when initially setting a unicast route or to provide 

the input port 50i including the packet header and an input firewall protection by initially examining certain routes or 

port 50/ identifier, and information from the class logic 60. flows or when it is unknown where in the packet required 

The merge logic 66 is connected to the class logic 60, the 4S information may exist to create search keys. Third, use layer 

associated memory 42, the packet memory manager 54, and 2 results for forwarding. Fourth, discard the packet. Other 

the processor 32. The merge logic 66 uses information from action may be possible depending on the configuration of the 

the class logic 60 and information output from the associated network or the particular protocol in use as would become 

memory 42 to instruct the input port 50( what to do to readily apparent to one skilled in the art. 

properly forward the packet to its appropriate destination(s). 50 Some of the criteria that the classes take into account may 

In some instances, there is no appropriate destination and the be whether the class is considered address dependent or 

packet is discarded. In other instances, the merge logic 66 address- independent. Adding a class identifier allows the 

will signal the processor 32 that it must perform some task switching element 36 to respond to varying network situa- 

in response to the received packet. tions and greatly simplifies organizing and storing informa- 

Layer 3 switching, while more complex, is similar to layer 55 tion in the forwarding memory 40. 
2 switching. The forwarding logic 52 searches the forward- Representative examples of address independent classes 
ing memory 40 for a matching entry to a layer 3 search key that could be identified by the class logic 60 include: 
created by the L3 logic 64. If a match exists, the information Address Resolution Protocol (ARP); Internet Group Man- 
in the associated memory 42 is used by the merge logic 66 agement Protocol (IGMP); Reverse ARP (RARP); Group 
to instruct the input port 50z what to do with the packet. If 60 Address Registration Protocol (GARP); Protocol Indcpcn- 
the search provides no match, the switching clement 36 dent Protocol (PIM); and Reservation Protocol (RSVP). 
forwards the packet as a bridge and may pass all or portions Representative examples of address dependent classes 
of the packet to the processor 32 for further processing. The include: TCP flow; non fragmented UDP flow; fragmented 
L3 logic 64 creates the search key using information from UDP flow; hardware rouiable IP; and IP version 6. Of 
the packet header, the input port 50/, and the class logic 60. 65 course, other protocols could be similarly recognized. 

The class logic 60 examines information in the packet The class logic 60 produces an unambiguous class result 

header to determine any encapsulation information and to for every incoming packet. For an unrecognized protocol, 
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the class logic 60 will still produce a class result, but that by the class logic 60 of the multi-layer network element 12, 

class result signifies an unrecognized protocol and wbat and the multi-layer network element 12, must then forward 

actions should take place on a packet of this type of class. the packet to the next hop destination, which is determined 

Generally, layer 3 flows are address dependent and will by routing protocols. Those skilled in the art can easily 

contain information beyond just a simple class of traffic. In 5 recognize from the invention other situations where such a 

those instances where additional information has been type 0 f rcsu i t would be desired 

P' a ^y t^Tnr ll^J 0 ™? "f T°? T 0ne fMWre ° f the ioventi °° " '"e ability to bridge flows, 

tnere may be more than one entry for a particular class in the .... r . ; , . 6 . , * 

forwarding memory 40. The processor 32 ensures that of the hat ™ lhc *>™*"* ™? 0 * to q^ckly forward layer 

entries matched, the one used is the most appropriate one. 10 2 ™ n * lay " r 3 ^^hty through the network 

Different classes may have different criteria for what is the 10 *™ C f rtai , n Aows^ Particularly suited for this type 

most appropriate match depending on the type of packets °J aCllVlty an ? lDclude 5 atlc flows > f tf "^"? e ^ ^ 

embodied within a particulaT class* The flexibility avowed * 0WSSCl U h P by n « cn ? !l » P^tocols such as RSVP. Static 

by having multiple matching entries in the forwarding fl ° WS f are * f u f m , *? nc ?. by * e D f etW °* elemCDt " 

memory 40 is further enhanced by ensuring that the best 1S °^ rat0 J * n L defit * layer 3 ^lonality for selected layer 2 

match is provided for a particular flow and because of this 15 ° etWOrk Ua ® C and are f ° 0t ^ 10 ^ Self-detecting 

feature, different actions will be possible for packets within fl ° f WS « 2 ^ nctl ° n ° f lhc of *PP hcat ™- 

the same type of class Initially, these flows are bridged with no layer 3 func- 

In the preferred embodiment, the processor 32 reorders !? 0nality becausc n u ° layer 3 cnt % f matcbes ' ™ e P acket 

the layer 3 entries when it places any new layer 3 so that the 20 headcr 15 * nl l ? the P rocessor & *>* examination. The 

best match for a particular search criteria occurs earliest in P rOCeSSOr 32 analyZCS ^ packet and based on P^ammed 

the memory. IW skiUed in the art will recognize many "eunstics determines whether and how to create a layer 3 

different implementations to achieve the same result. In one eDlry l ° the forwardin B memor y « for the packet type. For 

preferred embodiment, the processor 32 ensures that the exam P le » a M P in S P ack * W ™W not warrant a layer 3 flow 

entry with the longest potential matching key within a 25 entry because 11 1S - at ***** a transieDt P a <* e t- 

particular class is at the top, or earliest, location in the Protocols like RSVP work to reserve certain service 

memory. However, the processor 32 may also place an entry features of the network and signal that a number of packets 

above the longest matching entry so that for a particular will follow this same path. In this case, it serves the 

traffic pattern the most important match may be one that application using the reservation protocol to forward at layer 

matches many keys. For example, an entry that matches, for 30 2 > buI add laver 3 * or more » functionality like priority to 

a particular class, based on an application port such as "http" ensure lhe rec l uired ciass of service through the multi-layer 

and no other information, will take precedence over entries network element 12. 

that might match more than just the layer 4 application. FIG. 6 illustrates preferred results produced by the merge 

Another example might be forcing a match on a particular l°g* c 66 using information from the class logic 60 and the 

source within a class type. This might occur when the 35 associated memory 42. Three results arc presently preferred: 

operator might want to provide packets coming from a (1) use the layer 2 forwarding results; (2) use the layer 3 

particular server with a high priority regardless of the forwarding results; and (3) use the layer 3 results while using 

destination or layer 4 application. toe layer 2 topology. In some instances, there may be an 

In a preferred embodiment, the merge logic 66 directs the identified class, but no matching entry in the forwarding 

input port 50/ to take one of the following actions on a 40 me mory 40, in this instance, the default actions for the class 

packet: filter the packet; forward the packet at layer 2; are used * Note lnat the use of layer 3 default results can be 

forward the packet as a layer 3 flow; process the packet as considered a subset of using layer 3 forwarding results, 

a layer 3 route; and forward the packet as a multicast route. Default results may be set for packets of a class type to 

Packets that the merge logic 66 instructs the input port 50/ provide protection such as that provided by firewall tech- 

to filter are those that include certain header information 45 nology. In a firewall application, the multi-layer network 

determined to be unsupported. Examples of classes whose element 12 would be programmed to direct any packet of a 

packets would be forwarded at layer 2 would include a defined class to the processor 32 for subsequent processing, 

fragmented UDP flow and a class indicating that the header Referring to FIG. 6, if the class logic 60 determines that 

information is unknown. A fragmented UDP operates using the packet is of an unrecognized class (step 112), then the 

layer 2 information because after the first packet, the frag- 50 packet is acted on using the layer 2 results (step 114). If the 

mented packets do not include all relevant information from packet's class is recognized (step 112) and the associated 

the layer 4 header information, UDP ports for example. memory 42 or class logic 60 indicates that a layer 2 result 

Layer 2 forwarding would be optional for address indepen- should be forced (step 116), then the layer 2 results are used 

dent classes depending on the particular class. (step 118) regardless of any other information. 

The merge logic 66 instructs the input port 50/ to use layer 55 If no layer 2 results are forced as a result of the layer 2 

3 flow information for TCP or non-fragmented UDP flows. search (step 116) and there is a match of the layer 3 key (step 

Flows are those packets forwarded within the subnet to 120), then the layer 3 information is checked 10 to determine 

which the multi-layer network element 12 is attached and whether the layer 3 information forces a layer 2 port decision 

require no header modification on forwarding. Routes, on (step 122). 

the other hand, are packets coming from sources outside the 60 If the layer 3 information forces a layer 2 forwarding 

subnet or destined to addresses beyond the subnet such that result, then the output port is determined by the results of the 

the header information must be modified prior to forwarding layer 2 search, however, any other information found in the 

by the multi-layer network element 12. In a preferred results of the layer 3 search are applied (step 124) such as 

embodiment, instructions to forward the packet as a layer 3 QoS factors. If the layer 3 results do not call for forcing a 

route come from the merge logic 66 when the class indicates 65 layer 2 forwarding result, then the layer 3 results are passed 

that the packet is of a class hardware routable IP. In other on to the input port 50/ (step 126). If there is no layer 3 

words, the destination of the incoming packet is recognized match in step 120, then the default actions for the class 
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genera ted by the class logic 66 are passed to the input port also includes an indicator for which output ports 56 should 

50/ (step 128). It is also contemplated that a packet is sent use Best Effort in transmitting the packet. Best Effort implies 

to the processor 32 without being forwarded to any output that no guarantee on the packet's transmission or QoS is 

port 56 by the input port 50/ when using L3 class default provided. Those skilled in the art will easily recognize that 

action. 5 the invention applies equally well to other QoS as well. 

Thus, if the class is recognized and the layer 3 search The entry may also indicate whether a new lag should be 

• matches an entry, then the actions defined by the layer 3 applied to an outgoing packet when, for example, whether 

search govern the instructions to the input port 50/, even routing between VLANs requires an outgoing tag different 

though that might mean that the layer 2 output port results from the incoming tag, and what that tag should be, if 

are used. If not, the packet is treated using layer 2 results and 10 necessary. 

the packet or the packet's header might be sent to the The entry also contains information relating to source and 

processor 32 for subsequent processing of the layer 3 destination aging. Source aging information indicates 

information, if desired. whether the source is active or not. In a preferred 

If the information coming out of associated memory 42 implementation, this information is updated by the forward- 

for a layer 3 match indicates a force layer 2 result, then 15 ing logic 52 every time the layer 2 source address is 

packet forwarding is done using the layer 2 results, but any matched. The information implements in accordance with 

information relating to quality of service may still be imple- IEEE standard 802.1d type address aging. Destination aging 

mented on a layer 2 forwarding decision. In this way, the in the network element 12 indicates which layer 2 and layer 

multi-layer network element 12 may add additional func- 3 entries are active. The information for an entry is updated 

tionality above and beyond normal layer 2 bridges by 20 every time an entry is matched, either by a layer 2 destina- 

allowing quality of service factors to be applied to layer 2 tion search or a layer 3 match cycle for the entry, 

bridging or routing within the same subnet or VLAN. The entry also provides for whether layer 2 results should 

Accordingly, the input port 50/ presents to the forwarding be used for forwarding by the input port 50i. As mentioned 

logic 52 the header of the received packet and its port above, the layer 2 information may be forced for a layer 3 

designation. The output of the forwarding logic 52 is a 25 entry but in addition to the layer 2 forwarding information, 

function of the header information and the arrival port and layer 3 functionality may be added to the layer 2 forwarding, 

indicates whether the input port 50/ should store the packet The entry may also define a static entry. Astatic entry is 

in the packet buffer memory 44 in cooperation with the not subject to layer 2 learning and is never aged, 

packet memory manager 54; whether any priorities should 3Q Entries for layer 3 may include additional information, 

be associated with the packet on a particular output port 56/; The entry may indicate that only the first 64 byles of the 

and whether the input port 50/ should make any modifica- packet should be sent to the processor 32 for subsequent 

tions to the packet such as header replacement prior to processing. The entry may indicate whether the packet is 

passing the packet to the packet buffer memory 44. Thus, an pan of a multicast routing. If so, then the output port 50/ 

output port 56/ need not make any modifications to the 3S should decrement the header checksum, forward the packet 

header except for inserting its MAC address and computing t0 the indicated output ports 56, and indicate that the output 

a new packet checksum when routing unicast or multicast port 56/ need to replace the layer 2 source address of the 

packets, for example. packet the oulpul ^ 56fs address 0ther types of 

The layer 2 and layer 3 information in the forwarding header modifications will be readily apparent to those skilled 

memory 40 are independent of each other as applied to 40 in the art to implement proper routing, 

searches although some information contained in a layer 2 The entry in the associated memory 42 may also include 

entry may be duplicated in a layer 3 entry. Additionally, a the next hop destination address to be used to replace the 

layer 3 entry may also contain some layer 4 information such incoming destination in unicast routing. In a unicast route, 

as the UDP or TCP ports. Those skilled in the art would the incoming packet would have had its destination address 

readily recognize other features that could be added by 45 as the multi-layer network element 12 

including other information from other header layers or the Th e merge logic 66 musl wait for lQe resuUs of lhe 

packet body and such arc considered to be within the scope marches of the forwarding memory 40 done by the L2 logic 

of this invenhon^After both the layer 2 and layer 3 searches 62 an d the L3 logic 64. In the preferred embodiment, The 

are completed the merge logic 66 determines what actions Ia yer 2 and layer 3 information are stored in the same 

the input port 50 £ should do to the packet. $Q forwarding memory 40, however, they could be stored in 

Any layer 2 learning of source addresses, or changes that separate memories. As slated earlier, the preferred embodi- 

might occur as a result of a topology change are communi- ment has the forwarding memory 40 limited to storing the 

cated to the processor 32 as part of the layer 2 source search. information used by the L2 and L3 logics that match the 

As mentioned earlier, the layer 2 information may include fields of the key to reduce the size of the forwarding 

tagged information like that used to support virtual LAN 55 memory. As such, the associated memory 42 stores addi- 

(VLAN) information. When and, if used, the VLAN infor- tional information about the entries. Each entry in the 

mation helps to restrict layer 2 flooding to only those ports forwarding memory 40 points to a corresponding entry in 

associated with a particular VLAN or specific tagging. the associated memory 42, the contents of which the asso- 

Each entry in the associated memory 42 may contain ciated memory 42 provides to the merge logic 66 to makes 

information relating to the following outcomes. The entry 60 its forwarding decisions. 

includes an indication of the output ports 56 for the packet FIG. 7 illustrates the steps occurring in the forwarding 

including whether all or portions of the packet should be sent logic 52. While the FIG. 7 illustrates the preferred embodi- 

to the processor 32. The entry allows for more than one port ment of the operation of the forwarding logic 52, those 

56/ to be specified, if needed, to support for example skilled in the art will immediately recognize other equivalent 

multicast addressing, for example. The entry also includes a 65 ways to accomplish the same task. Information is received 

priority for the packet which maps into the number of output at the forwarding logic 52 from the input port 50 (step 200). 

queues which may be present on an output port 56. The entry On one path, the L2 logic 62 determines the necessary 
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information for a layer 2 search and carries out that search 
against the forwarding memory 40 (step 202), The L2 logic 
62 and forwarding memory 40 determine in step 204 
whether there was a matching entry for the source of the 
packet (step 204). If the source address is not in the 5 
forwarding memory 40, then the source address is learned 
(step 206). To learn the source address, the L2 logic 62 and 
the forwarding memory 40 ensure that an entry is placed in 
the forwarding memory. A signal is sent to the processor 32 
to examine the new information. 10 

If the source address was already in the forwarding 
memory 40 and matched to the input port 50 of arrival, then 
the L2 logic 62 attempts to match the destination address to 
the forwarding memory 40 (step 208). If the source address 
was not in the forwarding memory 40 or the source address is 
was in the memory but at a different port, then the source 
address and port combination is learned in step 206 prior to 
attempting a destination search in step 208. 

In the other path from step 200, the class logic 60 
determines the class in step 210. After the class logic 60 has 20 
determined the class and passed this onto the L3 logic 62, the 
L3 logic attempts a match against the forwarding memory 
for the layer 3 entry (step 212). 

In step 214, the merge logic 66 uses information from the 
L2 search of step 208, if there was one, the class logic results 25 
from step 210, and the layer 3 search results from step 212 
to make the appropriate forwarding decisions based on/the 
criteria of FIG. 6. Once the merge logic 66 has determined 
the appropriate forwarding decision in step 214, the results 
are passed to the output port 50i (step 216). 

FIG. 7 illustrates the flow proceeding down two paths. 
Because the layer 2 and layer 3 searches are independent, 
everything but the actual memory search may be pipelined 
or accomplished in parallel. In a preferred implementation, 
the processing by the class logic 60, the L2 logic 62, and L3 
logic 64 may proceed in a parallel or pipelined fashion 
except where dependencies prevent such action. For 
example, the L3 logic 64 requires the output of the class 
logic 60 to create the search key for the layer 3 search and 4Q 
the merge logic 66 requires that the layer 2 and layer 3 
searches be finished to merge the results according to FIG. 
6, 

In another embodiment, however, the L2 information and 
the L3 information may be in separate memories. In this case 45 
the L2 and L3 searches may occur simultaneously. 

After the merge logic 66 determines the actions on the 
packet, the input port 50/ makes write requests to the packet 
manager 54 if the packet is not to be filtered, or dropped. The 
packet need not be received in its entirety before the input 50 
port 50* makes write requests to the packet manager 54. The 
input port 50/ passes to the packet manager 54 the address 
where the incoming portion of the packet is to be stored, the 
number of output ports 56 that the packet will be output, the 
priority of the packet, and then delivers the pointers to the 55 
appropriate output port(s) 56. The input port 50** receives 
pointers to free memory locations in the packet buffer 
memory 44 where the packet may be placed. Preferably, the 
input port 50/ has obtained a pointer from the packet buffer 
manager 54 prior to making write requests. 60 

The output port 56* stores the pointers in output queues 
for packet transmission. When a queue presents a pointer for 
transmission, the output port 56t requests the contents stored 
at the pointer address from the packet manager 54 and 
transmits the contents out of the multi-layer network ele- 65 
ment 12 on the-corresponding network element port 38. The 
packet manager 54 keeps track of whether all of the output 



port 56 using a particular pointer have transmitted the 
contents associated with that pointer, if so the memory space 
is freed for future use. 

In the preferred embodiment, the switching element 36 
and all of its constituents are implemented in hardware. 
Also, in the preferred embodiment, the forwarding memory 
40 and associated memory 42 are implemented in hardware. 

In an alternate preferred embodiment, the switching ele- 
ment 36 and all its constituents are implemented in hardware 
on an application specific integrated circuit. Equally 
contemplated, an integrated circuit could contain a hardware 
implementation of switching element 36, and any combina- 
tion or portion thereof, of the processor 32, the processor 
memory 34, the forwarding memory 40, the associated 
memory 42, and the packet buffer memory 44. 

A multi-layer network element has been described that 
combines the features of quick layer 2 bridge-type forward- 
ing and combines it with the added functionality of layer 3 
routing and QoS support to create an apparatus and method 
of its use to perform both layer 2 and most layer 3 forward- 
.ing decisions prior to the receipt of the next packet. 

The foregoing description of the preferred embodiments 
of the multi-layer network element has been presented for 
purposes of illustration and description. It is not intended to 
be exhaustive or to limit the invention to the precise form 
disclosed, and modification and variations are possible in 
light of the above teachings or may be acquired from 
practice of the invention as disclosed. The embodiments 
were chosen and described in order to explain the principles 
of the invention and its practical application to enable one 
skilled in the art to utilize the invention in various embodi- 
ments and with variation modifications as are suited to the 
particular use contemplated. It is intended that the scope of 
the invention be defined by the claims appended hereto, and 
their equivalents. 

What is claimed is: 

1. Amethod for making a forwarding decision for a packet 
entering a network element having at least one input port and 
at least one output port, wherein the packet enters the 
network element on an input port and exits the network 
clement on appropriate output ports, if any, including the 
steps of: 

(1) receiving a first header portion of the packet; 

(2) determining a first search key from the first header 
portion; 

(3) causing a memory to output first forwarding informa- 
tion associated with the first search key; 

(4) receiving a second header portion of the packet; 

(5) determining a class information for the packet based 
on the second header portion, wherein each class infor- 
mation includes a class, second header key information 
indicating which fields of the second header portion 
should be used to create a second search key, and 
default forwarding information for packets falling 
within the class; 

(6) creating the second search key from the second header 
portion based on the second header portion key infor- 
mation; 

(7) causing the memory to output second forwarding 
information, if any, associated with the second search 
key; 

(8) determining the appropriate output ports, if any, based 
on the first forwarding information, the second for- 
warding information, and the default forwarding infor- 
mation. 
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2. The method of claim 1, wherein: 

St6 H ji! ) n ! , i , DClUdeS B determinin 8. « a function of the first 
*TX' ' firSt Wb0M «>"«Pondiog con- 

mln; and ""*" ta forWardin8 

step (7) includes determining, as a function of the search 
key, a second address, whose corresponding contents 

3 T? ,be , SeC0Dd f0 ™^g information. 

J. The method of claim 2, wherein determining the first 

w1 d hT e fi nCl !f eSSe4rCl,iD8 4 ^ot-addressable memo" 
with the first dest.nat.on address to produce the first address! 

d ?d7r3 lhC SeC ° nd bc,udM searchin 8 ,bc «"««'- 
SEEST"* W ' th ^ X " Cb kCy '° produc ° < b ° 

JL$* T ,h ° d ° f daitD 2 ' further including the step of 
providing the memory as , firsI memory for storing fi* 
forwarding information and a second memory fo™Li£ 
second forwarding information. V 8 

5. The method of claim 3, further including the steo of 
prov^drng the content-addressable memory as a fiS contem- 
addressable memory that stores the first address and a 
se^ndconten^ddressable that stores the seconded"! 
xHr^T T!? Claim 2 ' wnerein determining the first 

£ fn„ , USW . g * haShin 6 f"" 0 " 0 " °° first des- 

tination to produce the first address; and 

determining the second address includes using a hashing 
faction on the search key to produce the second 

7. The method of claim 1, wherein step (8) is carried out * 
using only the first forwarding information ■ when™ firs 
forwarding information so indicates. 

8. The method of claim 1, wherein step (8) is carried out 
u^mg only the first forwarding information When the Tcond 3S 
forwarding information so indicates. 35 

9. The method of claim 1, wherein step (8) is carried out. 

d5£ T a- °° K *• ** { °™<1*Z information and 
default forwarding information. 

10. The method of claim 9. wherein step (8) is carried out 4 ° 

?orw g ardt ,be f firSl k{ ° milioa wben tb * «2 

forwarding information so indicates and the second search 
key fads to output second forwarding information. 

11. The method of claim 1, wherein step (8) is carried n„t 
using only the second forwarding information 45 

usino = T T* 0 - ° f I™ l ' Wberein sle P ( 8 ) is "fried out 
second f ~ mbinaU0D °/ ,be fir* forwarding information and 
second forwarding information. 

mitnfl h l? lh0d ? f f 1 *™ wberein ,be «cond forward- 

14. me method of claim 13, wherein the quality of service 
information includes a priority for the pac £« X C 
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search logic configured to output, based on the header, a 
first search key, and, based on the header, the class, and 
tbe key information, a second search key; 
a memory configured to output a first forwarding result in 
response to the firs! search key, aod outputs a second 
forwarding result, if any, in response to tbe second 
search key; 

merge logic configured to output information about 
appropriate output ports in response to the default 
forwarding information, the first forwarding result, and 
the second forwarding result; and 
forwarding logic configured to direct the packet from the 
input port to the appropriate output ports, if any, based 
on the information about the appropriate output ports 
include? 6 4PparatUS ° f daim 15> wberein lhe memory 

interface logic configured to output, as a function of the 
first search key, a first address, and that outputs, as a 
function of the second search key, a second address; 
and 

wherein the memory is configured to output the first 
forwarding results in response to tbe first address and 
output the second forwarding results in response to the 
second address. 

include? 1 * appaMtUS of cUim 15 ' wnerei n the memory 

a content-addressable memory configured to output a first 
forwarding information address when accessed using 
the first search key, and a second forwarding informa- 
tion address when accessed using tbe second search 
key; and 

a forwarding memory configured to output the first for- 
warding result when accessed using the first forwarding 
information address, and outputs tbe second forwarding 
address when accessed using the second forwarding 

18. The apparatus of claim 17, wherein the interface logic 
is a content-addressable memory. ^ 

19. Tbe apparatus of claim 18, wherein the content- 
addressable includes: 

* S# P°° t . cn, - ad drcssablc memory configured to output 
the firs forwarding information address when accessed 
using the first search key; and 
a second content-addressable memory configured to out- 
put the second forwarding information address when 
ac ff ssed "sing the second search key. 

20. The apparatus of claim 17. wherein the default for- 
50 warding information and the second forwarding result con- 
tains quality of service information. 

™ 2 !' Th V Ppar4tUS ° f Claim 17 ' wbercin the merge logic is 



„,„i~,. u — »"«~u & a Lurwaraing aecision tor a — u a r uluuUflUU " doom appropriate output 

fc > llT ? be4der ' ' be packet P r ° v *ed «s inpu ss K^i" C me . m0ry f3ils 10 ou, P ut Second forward- 

east one ^ , emem h4Vin8 at ,east 0De Wui port and a " ^ ' lhe forwarding information and 

lemen. r° T ^ Whenia the P acket entere network ,be „ fils « folw "d.ng result, 

one or L° P and exits ne,work element on "J *, appara,us of cIaim therein the default for- 

one or more appropriate output ports, if any, comprising: »fcnntuon contains quality of service information. 

within the class; ««ing 
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